Cleanup LLVMDWARFDebugInfo

As usual with that header cleanup series, some implicit dependencies now need to
be explicit:

llvm/DebugInfo/DWARF/DWARFContext.h no longer includes:
- "llvm/DebugInfo/DW

Cleanup LLVMDWARFDebugInfo

As usual with that header cleanup series, some implicit dependencies now need to
be explicit:

llvm/DebugInfo/DWARF/DWARFContext.h no longer includes:
- "llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h"
- "llvm/DebugInfo/DWARF/DWARFCompileUnit.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAbbrev.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAranges.h"
- "llvm/DebugInfo/DWARF/DWARFDebugFrame.h"
- "llvm/DebugInfo/DWARF/DWARFDebugLoc.h"
- "llvm/DebugInfo/DWARF/DWARFDebugMacro.h"
- "llvm/DebugInfo/DWARF/DWARFGdbIndex.h"
- "llvm/DebugInfo/DWARF/DWARFSection.h"
- "llvm/DebugInfo/DWARF/DWARFTypeUnit.h"
- "llvm/DebugInfo/DWARF/DWARFUnitIndex.h"

Plus llvm/Support/Errc.h not included by a bunch of llvm/DebugInfo/DWARF/DWARF*.h files

Preprocessed lines to build llvm on my setup:
after: 1065629059
before: 1066621848

Which is a great diff!

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119723

show more ...

DebugInfo: Sink string form validation down from verifier to form parsing

Avoid duplicating the string decoding - improve the error messages down
in form parsing (& produce an Expected<const char*>

DebugInfo: Sink string form validation down from verifier to form parsing

Avoid duplicating the string decoding - improve the error messages down
in form parsing (& produce an Expected<const char*> instead of
Optional<const char*> to communicate the extra error details)

show more ...

DebugInfo: Fix incorrect line table lookup when resolving decl_file from a split unit

Specifically in DWARFv5 the unit for the line table entry was correct
but the context was incorrect - leading to

DebugInfo: Fix incorrect line table lookup when resolving decl_file from a split unit

Specifically in DWARFv5 the unit for the line table entry was correct
but the context was incorrect - leading to looking up .debug_line_str in
the dwp instead of the executable.

(perhaps we could/should remove the context pointer entirely, and rely
on the one in the unit... I might try that as a separate follow-up
commit)

show more ...

Fixed some errors detected by PVS Studio

Fix DWARFDie::getDeclFile(...) to work with DW_AT_specification.

DWARFDie::getDeclFile(...) previously only supported getting the DW_AT_decl_file if the DIE itself contained the DW_AT_decl_file attr

Fix DWARFDie::getDeclFile(...) to work with DW_AT_specification.

DWARFDie::getDeclFile(...) previously only supported getting the DW_AT_decl_file if the DIE itself contained the DW_AT_decl_file attribute, or if the DIE had a DW_AT_abstract_origin that pointed to another DIE that had a DW_AT_decl_file. This patch allows the function to get the right attribute value if there is a DW_AT_specification that points to another DIE. We also test that if a DW_AT_abtract_origin or DW_AT_specification points to a DIE in another CU with a DW_FORM_ref_addr, that the right line table is used to extract the file index.

Full tests were added for the following cases:
- DIE has a DW_AT_decl_file attribute
- DIE has a DW_AT_abtract_origin that points to another die in the same CU
- DIE has a DW_AT_abtract_origin that points to another die in another CU
- DIE has a DW_AT_specification that points to another die in the same CU
- DIE has a DW_AT_specification that points to another die in another CU

Differential Revision: https://reviews.llvm.org/D108480

show more ...

llvm-dwarfdump: Fix DWARF-5 DW_FORM_implicit_const (used by GCC)

Differential Revision: https://reviews.llvm.org/D98195

DebugInfo: Add a DWARF FORM extension for addrx+offset references to reduce relocations

This is an alternative to the use of complex DWARF expressions for
addresses - shaving off a few extra bytes o

DebugInfo: Add a DWARF FORM extension for addrx+offset references to reduce relocations

This is an alternative to the use of complex DWARF expressions for
addresses - shaving off a few extra bytes of expression overhead.

show more ...

llvm-dwarfdump: Dump address forms in their encoded length rather than always in 64 bits

Few places did this already - refactor them all into a common helper.

[DebugInfo] Dump form values according to the DWARF format (2/8).

The patch changes dumping of DWARF form values which sizes depend on
the DWARF format so that they are printed as 16-digit hex value

[DebugInfo] Dump form values according to the DWARF format (2/8).

The patch changes dumping of DWARF form values which sizes depend on
the DWARF format so that they are printed as 16-digit hex values for
DWARF64.

Differential Revision: https://reviews.llvm.org/D79997

show more ...

[DebugInfo] Fix printing values of forms which depend on the DWARF format.

The values are 8 bytes long in DWARF64, so they should not be truncated
to uint32_t on dumping.

Differential Revision: htt

[DebugInfo] Fix printing values of forms which depend on the DWARF format.

The values are 8 bytes long in DWARF64, so they should not be truncated
to uint32_t on dumping.

Differential Revision: https://reviews.llvm.org/D79093

show more ...

[DWARF] Detect extraction errors in DWARFFormValue::extractValue

Summary:
Although the function had a bool return value, it was always returning
true. Presumably this is because the main type of err

[DWARF] Detect extraction errors in DWARFFormValue::extractValue

Summary:
Although the function had a bool return value, it was always returning
true. Presumably this is because the main type of errors one can
encounter here is running off the end of the stream, and until very
recently, the DataExtractor class made it very difficult to detect that.

The situation has changed now, and we can easily detect errors here,
which this patch does.

Reviewers: dblaikie, aprantl

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77308

show more ...

DebugInfo: Don't use implicit zero addr_base

(found when LLVM fails to emit addr_base for gmlt+DWARFv5)

DebugInfo: Use loclistx for DWARFv5 location lists to reduce the number of relocations

This only implements the non-dwo part, but loclistx is necessary to use
location lists in DWARFv5, so it's a pr

DebugInfo: Use loclistx for DWARFv5 location lists to reduce the number of relocations

This only implements the non-dwo part, but loclistx is necessary to use
location lists in DWARFv5, so it's a precursor to that work - and
generally reduces relocations (only using one reloc, then
indexes/relative offsets for all location list references) in non-split
DWARF.

show more ...

Remove support for 32-bit offsets in utility classes (5/5)

Differential Revision: https://reviews.llvm.org/D65641

llvm-svn: 368156

Support 64-bit offsets in utility classes (1/5)

Using 64-bit offsets is required to fully implement 64-bit DWARF.
As these classes are used in many different libraries they should
temporarily suppor

Support 64-bit offsets in utility classes (1/5)

Using 64-bit offsets is required to fully implement 64-bit DWARF.
As these classes are used in many different libraries they should
temporarily support both 32- and 64-bit offsets.

Differential Revision: https://reviews.llvm.org/D64006

llvm-svn: 368013

show more ...

[DWARF][RISCV] Add support for RISC-V relocations needed for debug info

When code relaxation is enabled many RISC-V fixups are not resolved but
instead relocations are emitted. This happens even for

[DWARF][RISCV] Add support for RISC-V relocations needed for debug info

When code relaxation is enabled many RISC-V fixups are not resolved but
instead relocations are emitted. This happens even for DWARF debug
sections. Therefore, to properly support the parsing of DWARF debug info
we need to be able to resolve RISC-V relocations. This patch adds:

* Support for RISC-V relocations in RelocationResolver
* DWARF support for two relocations per object file offset
* DWARF changes to support relocations in more DIE fields

The two relocations per offset change is needed because some RISC-V
relocations (used for label differences) come in pairs.

Relocations can also be emitted for DWARF fields where relocations were
not yet evaluated. Adding relocation support for some of these fields is
essencial. On the other hand, LLVM currently emits RISC-V relocations
for fixups that could be safely evaluated, since they can never be
affected by code relaxations. This patch also adds relocation support
for the fields affected by those extraneous relocations (the DWARF unit
entry Length, and the DWARF debug line entry TotalLength and
PrologueLength), for testing purposes.

Differential Revision: https://reviews.llvm.org/D62062
Patch by Luís Marques.

llvm-svn: 366402

show more ...

[DWARF] hoist nullptr checks. NFC

Summary:
This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No.
15" (see under #13). It looks like PVS studio flags nullptr checks where
the ptr i

[DWARF] hoist nullptr checks. NFC

Summary:
This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No.
15" (see under #13). It looks like PVS studio flags nullptr checks where
the ptr is used inbetween creation and checking against nullptr.

Reviewers: JDevlieghere, probinson

Reviewed By: JDevlieghere

Subscribers: RKSimon, hiraditya, llvm-commits, srhines

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D62118

llvm-svn: 361176

show more ...

DebugInfo: Only move types out of type units if they're named or type united

Follow up to r359122, after a bug was reported in it - the original
change too aggressively tried to move related types o

DebugInfo: Only move types out of type units if they're named or type united

Follow up to r359122, after a bug was reported in it - the original
change too aggressively tried to move related types out of type units,
which included unnamed types (like array types) which can't reasonably
be declared-but-not-defined.

A step beyond that is that some types in type units can be anonymous, if
they are types with a name for linkage purposes (eg: "typedef struct { }
x;"). So ensure those don't get turned into plain declarations (without
signatures) because, lacking names, they can't be resolved to the
definition.

[Also include a fix for llvm-dwarfdump/libDebugInfoDWARF to pretty print
types in type units]

llvm-svn: 360458

show more ...

Change some StringRef::data() reinterpret_cast to bytes_begin() or arrayRefFromStringRef()

llvm-svn: 357852

[DWARFFormValue] Don't consider DW_FORM_data4/8 to be section offsets.

When dumping ToT clan's debug info with dwarfdump, we were seeing an
error saying that that the location list overflows the deb

[DWARFFormValue] Don't consider DW_FORM_data4/8 to be section offsets.

When dumping ToT clan's debug info with dwarfdump, we were seeing an
error saying that that the location list overflows the debug_loc
section. After reducing the testcase we figured out that we were
interpreting the DW_FORM_data4 as a section offset.

In DWARF3 DW_FORM_data4 and DW_FORM_data8 served also as a section
offset. Until now we didn't check check for the DWARF version, because
some producers (read old versions of clang) were still emitting this.
The relevant code/comment was added in 2013, and I believe it's now
reasonable to start checking the version.

The FormValue class is a little bit of a mess because it cashes the
DWARF unit and context when it extracted the value itself. Several
methods of the class rely on it being present, or return an Optional for
the code path that needs it. At the same time the FormValue class also
used in places where there's no DWARF unit.

For this patch I went with the least invasive change: checking the
version from the CU when it's available. If it's not (because the form
value was created from a value directly) we default to the old behavior.

Differential revision: https://reviews.llvm.org/D58698

llvm-svn: 355456

show more ...

Revert "[DWARFFormValue] Cleanup DWARFFormValue interface. (2/2) (NFC)"

This reverts commit r355233, it was causing UBSan failures.

llvm-svn: 355255

[DWARFFormValue] Cleanup DWARFFormValue interface. (2/2) (NFC)

Continues the work started in r354941. Changes (all but one) uses of the
extractValue to static createFromData.

llvm-svn: 355233

[DebugInfo] add SectionedAddress to DebugInfo interfaces.

That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703
"wrong line number info for obj file compiled with -ffunction

[DebugInfo] add SectionedAddress to DebugInfo interfaces.

That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703
"wrong line number info for obj file compiled with -ffunction-sections"
bug. The problem happened with only .o files. If object file contains
several .text sections then line number information showed incorrectly.
The reason for this is that DwarfLineTable could not detect section which
corresponds to specified address(because address is the local to the
section). And as the result it could not select proper sequence in the
line table. The fix is to pass SectionIndex with the address. So that it
would be possible to differentiate addresses from various sections. With
this fix llvm-objdump shows correct line numbers for disassembled code.

Differential review: https://reviews.llvm.org/D58194

llvm-svn: 354972

show more ...

[DWARFFormValue] Cleanup DWARFFormValue interface. (NFC)

DWARFFormValues can be created from a data extractor or by passing its
value directly. Until now this was done by member functions that
modif

[DWARFFormValue] Cleanup DWARFFormValue interface. (NFC)

DWARFFormValues can be created from a data extractor or by passing its
value directly. Until now this was done by member functions that
modified an existing object's internal state. This patch replaces a
subset of these methods with static method that return a new
DWARFFormValue.

llvm-svn: 354941

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...