Add verification support for .debug_names with foreign type units. (#109011)

This commit enables 'llvm-dwarfdump --veriy' to verify the DWARF in
foreign type units when using split DWARF for the .d

Add verification support for .debug_names with foreign type units. (#109011)

This commit enables 'llvm-dwarfdump --veriy' to verify the DWARF in
foreign type units when using split DWARF for the .debug_names section.

show more ...

Add support for using foreign type units in .debug_names. (#87740)

This patch adds support for the new foreign type unit support in
.debug_names. Features include:
- don't manually index foreign T

Add support for using foreign type units in .debug_names. (#87740)

This patch adds support for the new foreign type unit support in
.debug_names. Features include:
- don't manually index foreign TUs if we have info for them
- only use the type unit entries that match the .dwo files when we have
a .dwp file
- fix type unit lookups for .dwo files
- fix crashers that happen due to PeekDIEName() using wrong offsets where an entry had DW_IDX_comp_unit and DW_IDX_type_unit entries and when we had no type unit support, it would cause us to think it was a normal DIE in .debug_info from the main executable.

---------

Co-authored-by: paperchalice <liujunchang97@outlook.com>

show more ...

[DWARF] Clarify a variable name. NFC (#88814)

The parameter of `findDebugNamesOffsets` has been renamed to
`EndOfHeaderOffset` in #88064 to make it clear it is a section offset
instead of an offse

[DWARF] Clarify a variable name. NFC (#88814)

The parameter of `findDebugNamesOffsets` has been renamed to
`EndOfHeaderOffset` in #88064 to make it clear it is a section offset
instead of an offset relative to the current name index. Rename the call
site variable as well.

show more ...

[DWARF] Refactor findDebugNamesOffsets

Address some post-review comments in #82153 and move the function inside
llvm::dwarf, used by certain free functions.

Pull Request: https://github.com/llvm/ll

[DWARF] Refactor findDebugNamesOffsets

Address some post-review comments in #82153 and move the function inside
llvm::dwarf, used by certain free functions.

Pull Request: https://github.com/llvm/llvm-project/pull/88064

show more ...

[LLVM][DebugInfo] Refactor some code for easier sharing. (#82153)

Refactor the code that calculates the offsets for the various pieces of
the DWARF .debug_names index section, to make it easier to

[LLVM][DebugInfo] Refactor some code for easier sharing. (#82153)

Refactor the code that calculates the offsets for the various pieces of
the DWARF .debug_names index section, to make it easier to share the
code with other tools, such as LLD.

show more ...

[LLVM][DWARF] Chnage order for .debug_names abbrev print out (#80229)

This stemps from conversatin in:
https://github.com/llvm/llvm-project/pull/77457#discussion_r1457889792.
Right now Abbrev code

[LLVM][DWARF] Chnage order for .debug_names abbrev print out (#80229)

This stemps from conversatin in:
https://github.com/llvm/llvm-project/pull/77457#discussion_r1457889792.
Right now Abbrev code for abbrev is combination of DIE TAG and other
attributes.
In the future it will be changed to be an index. Since DenseSet does not
preserve an order, added a sort based on abbrev code. Once change to
index is
made, it will print out abbrevs in the order they are stored.

show more ...

[DebugNames] Compare TableEntry names more efficiently (#79759)

TableEntry names are pointers into the string table section, and
accessing their
length requires a search for `\0`. However, 99% of

[DebugNames] Compare TableEntry names more efficiently (#79759)

TableEntry names are pointers into the string table section, and
accessing their
length requires a search for `\0`. However, 99% of the time we only need
to
compare the name against some other other, and such a comparison will
fail as
early as the first character.

This commit adds a method to the interface of TableEntry so that such a
comparison can be done without extracting the full name. It saves 10% in
the
time (1250ms -> 1100 ms) to evaluate the following expression.

```
lldb \
--batch \
-o "b CodeGenFunction::GenerateCode" \
-o run \
-o "expr Fn" \
-- \
clang++ -c -g test.cpp -o /dev/null &> output
```

show more ...

[DebugNames] Use hashes to quickly filter false positives (#79755)

The current implementation of DebugNames is _only_ using hashes to
compute the bucket number. Once inside the bucket, it reverts b

[DebugNames] Use hashes to quickly filter false positives (#79755)

The current implementation of DebugNames is _only_ using hashes to
compute the bucket number. Once inside the bucket, it reverts back to
string comparisons, even though not all hashes inside a bucket are
identical.

This commit changes the behavior so that we check the hash before
comparing strings. Such check is so important that it speeds up a simple
benchmark by 20%. In other words, the following expression evaluation
time goes from 1100ms to 850ms.

```
bin/lldb \
--batch \
-o "b CodeGenFunction::GenerateCode" \
-o run \
-o "expr Fn" \
-- \
clang++ -c -g test.cpp -o /dev/null &> output
```

(Note, these numbers are considering the usage of IDX_parent)

show more ...

[DebugNames] Implement Entry::GetParentEntry query (#78760)

This commit introduces a helper function to DWARFAcceleratorTable::Entry
which follows DW_IDX_Parent attributes to returns the correspond

[DebugNames] Implement Entry::GetParentEntry query (#78760)

This commit introduces a helper function to DWARFAcceleratorTable::Entry
which follows DW_IDX_Parent attributes to returns the corresponding
parent Entry in the table.

It is tested by enhancing dwarfdump so that it now prints:

1. When data is corrupt.
2. When parent information is present, but the parent is not indexed.
3. The parent entry offset, when the parent is present and indexed. This
is printed in terms a real entry offset (the same that gets printed at
the start of each entry: "Entry @ 0x..."), instead of the encoded number
in the table (which is an offset from the start off the Entry list).
This makes it easy to visually inspect the dwarfdump and check what the
parent is.

show more ...

Add support for parsing type unit entries in .debug_names. (#72952)

This is a follow up patch after .debug_names can now emit local type
unit entries when we compile with type units + DWARF5 + .deb

Add support for parsing type unit entries in .debug_names. (#72952)

This is a follow up patch after .debug_names can now emit local type
unit entries when we compile with type units + DWARF5 + .debug_names.
The pull request that added this functionality was:

https://github.com/llvm/llvm-project/pull/70515

This patch makes sure that the DebugNamesDWARFIndex in LLDB will not
manually need to parse type units if they have a valid index. It also
fixes the index to be able to correctly extract name entries that
reference type unit DIEs. Added a test to verify things work as
expected.

show more ...

[DebugInfo] Use StringRef::starts_with/ends_with instead of startswith/endswith. NFC.

startswith/endswith wrap starts_with/ends_with and will eventually go away (to more closely match string_view)

[DWARF] Change to consistently print out abbrev code in .debug_names (#68353)

Changed so that when Abbrev code is printed out for entry it is done in
the same
way as in Abbrev table.
Once letters

[DWARF] Change to consistently print out abbrev code in .debug_names (#68353)

Changed so that when Abbrev code is printed out for entry it is done in
the same
way as in Abbrev table.
Once letters are present in a hex number in abbrev table they will be
lower case,
and in the Entry upper case. Which makes FIleCheck Pattern recognition
fail.
Example in: llvm/test/tools/llvm-dwarfdump/X86/debug-names-misaligned.s

show more ...

Revert "[LLVM][DWARF] Add support for monolithic types in .debug_names (#68131)"

This reverts commit 9bbd2bf654634cd95dd0be7948ec8402c3c76e1e.

Accidental commit: https://github.com/llvm/llvm-projec

Revert "[LLVM][DWARF] Add support for monolithic types in .debug_names (#68131)"

This reverts commit 9bbd2bf654634cd95dd0be7948ec8402c3c76e1e.

Accidental commit: https://github.com/llvm/llvm-project/pull/68131#issuecomment-1749430207

show more ...

[LLVM][DWARF] Add support for monolithic types in .debug_names (#68131)

Added support for Type Units in monolithic DWARF in .debug_names.

[DebugInfo][NFC] Move ObjC Selector name handling to lib DebugInfo

The DWARFLinker library has code to identify ObjC selector names, which is used
by the debug linker to generate accelerator table e

[DebugInfo][NFC] Move ObjC Selector name handling to lib DebugInfo

The DWARFLinker library has code to identify ObjC selector names, which is used
by the debug linker to generate accelerator table entries. In the future, we
would like the DWARF verifier to also have access to such code, so that it can
identify these names when verifying accelerator tables (e.g. debug_names).

This patch follows the same intent of D155723, where we also moved code
generating simplified template names.

Since this is moving code around and changing the log, we also replace raw
pointer manipulation with the more expressive
StringRef::{drop_front,take_front,...} methods.

We also change a test so that it verifies its output, and that requires having
dsymutil not write to stdout.

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

show more ...

[DWARFVerifier] Allow simplified template names in debug_name

LLDB can benefit from having the base name of functions (i.e. without any
template parameters) as an entry into accelerator tables point

[DWARFVerifier] Allow simplified template names in debug_name

LLDB can benefit from having the base name of functions (i.e. without any
template parameters) as an entry into accelerator tables pointing back in the
DIE for the corresponding function specialization. In fact, some LLDB
functionality is only possible when those entries are present.

The DWARFLinker has been adding such entries for a while now, both with
apple_names and with debug_names. However, this has two side effects:

1. Some LLDB functionality is only possible when dsym bundles are present (i.e.
the linker touched the debug info).
2. The DWARFVerifier doesn't accept debug_name sections created by the linker,
as such names are (usually) neither the AT_name nor the AT_linkage_name of the
DIE.

Based on recent discussion [1], and because the DWARF 5 spec says that:

> A producer may choose to implement additional rules for what names are placed
> in the index

This patch relaxes the checks on the verifier to allow for simplified template
names in the accelerator table. To do so, we move some helper functions from
DWARFLinker into the core lib debug info. This addresses the point 2) above.

This patch also enables addressing point 1) in the future, since the helper
function is now visible to other parts of LLVM.

[1]: https://github.com/llvm/llvm-project/issues/58362

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

show more ...

[AppleTables] Implement iterator over all entries in table

This commit adds functionality to the Apple Accelerator table allowing iteration
over all elements in the table.

Our iterators look like s

[AppleTables] Implement iterator over all entries in table

This commit adds functionality to the Apple Accelerator table allowing iteration
over all elements in the table.

Our iterators look like streaming iterators: when we increment the iterator we
check if there is still enough data in the "stream" (in our case, the blob of
data of the accelerator table) and extract the next entry. If any failures
occur, we immediately set the iterator to be the end iterator.

Since the ultimate user of this functionality is LLDB, there are roughly two
iteration methods we want support: one that also loads the name of each entry,
and one which does not. Loading names is measurably slower (one order the
magnitude) than only loading DIEs, so we used some template metaprograming to
implement both iteration methods.

Depends on D153066

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

show more ...

[nfc][AppleTables] Rename iterator

We will soon need different kinds of iterators
We also use one of LLVM's iterator classes to implement some basic iterator
operations.

Differential Revision: http

[nfc][AppleTables] Rename iterator

We will soon need different kinds of iterators
We also use one of LLVM's iterator classes to implement some basic iterator
operations.

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

show more ...

[DebugInfo] Fix detection of hash collision in Apple Accel tables

The current implementation was ignoring the possibility of collisions.

Differential Revision: D152586

Revert "[DebugInfo] Fix detection of hash collision in Apple Accel tables"

Committed a slightly older patch without the proper link to the review.

This reverts commit 42874f66475548541cd871d5790116

Revert "[DebugInfo] Fix detection of hash collision in Apple Accel tables"

Committed a slightly older patch without the proper link to the review.

This reverts commit 42874f66475548541cd871d5790116b2bc68b89a.

show more ...

[DebugInfo] Fix detection of hash collision in Apple Accel tables

The current implementation was ignoring the possibility of collisions.

[AppleAccelTable][NFC] Refactor iterator class

The current implementation of the AppleAcceleratorTable::Entry is problematic
for a few reasons:

1. It is heavyweight. Iterators should be cheap, but

[AppleAccelTable][NFC] Refactor iterator class

The current implementation of the AppleAcceleratorTable::Entry is problematic
for a few reasons:

1. It is heavyweight. Iterators should be cheap, but the current implementation
tracks 3 different integer values, one "Entry" object, and one pointer to the
actual accelerator table. Most of this information is redundant and can be
removed.

2. It performs "memory reads" outside of the dereference operation. This
violates the usual expectations of iterators, whereby we don't access anything
so long as we don't dereference the iterator.

3. It doesn't commit to tracking _one_ thing only. It tries to track both an
"index" into a list of HashData entries and a pointer in a blob of data. For
this reason, it allows for multiple "invalid" states, keeps redundant
information around and is difficult to understand.

4. It couples the interpretation of the data with the iterator increment. As
such, if the *interpretation* fails, the iterator will keep on producing garbage
values without ever indicating so to consumers.

The problem this iterator is trying to solve is simple: we have a blob of data
containing many "HashData" entries and we want to iterate over them. As such,
this commit makes the iterator only track a pointer over that data, and it
decouples the iterator increments from the interpretation of this blob of data.

We maintain the already existing assumption that failures never happen, but now
make it explicit with an assert.

Depends on D152158

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

show more ...

[AppleAccelTable][NFC] Improve code readability

This commit does a few minor NFC cleanups:

* A variable was called "Atom", probably trying to claim it was an AtomType.
This was incorrect, it is act

[AppleAccelTable][NFC] Improve code readability

This commit does a few minor NFC cleanups:

* A variable was called "Atom", probably trying to claim it was an AtomType.
This was incorrect, it is actually a FormValue.

* LLVM provides a `zip_equal` to express the intent of asserting ranges with the
same size. We change the lookup method to use that.

* The use of tuples made the code slightly difficult to follow, as such we
unpack the tuple with structure binding to improve readability.

Depends on D152157

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

show more ...

[AppleAccelTable] Keep track of the size of each hash data entry

In a future patch, it will be desirable to skip over all hash data entries for a
particular string. In order to do so, we must know h

[AppleAccelTable] Keep track of the size of each hash data entry

In a future patch, it will be desirable to skip over all hash data entries for a
particular string. In order to do so, we must know how many bytes each of those
entries have.

In its full specification, Apple tables allow for variable length entries, which
would make the above impossible without reading the data of each entry. However,
this is largely unsupported today (as a FIXME in the code indicates, there is a
bug with hash collisions exactly because we don't know how to skip over data),
and the documentation[1] states that:

> For the current implementations of the “.apple_names” (all functions +
> globals), the “.apple_types” (names of all types that are defined), and the
> “.apple_namespaces” (all namespaces), we currently set the Atom array to be:
> [...]
> This defines the contents to be the DIE offset (eAtomTypeDIEOffset) that is
> encoded as a 32 bit value (DW_FORM_data4).

In other words, we only produce fixed sized entries.

A few tests containing invalid dwarf had to be updated, as the error is now
detected earlier (when the accelerator table is being parsed, instead of inside
the explicit call to "verify").

[1]: https://llvm.org/docs/SourceLevelDebugging.html#fixed-lookup

Depends on D152156

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

show more ...

[AppleAccelTable][NFC] Make FormParams member of AppleAccelTable

These are used throughout the class and are recreated every time they are used.
To prevent the risk of it being created incorrectly i

[AppleAccelTable][NFC] Make FormParams member of AppleAccelTable

These are used throughout the class and are recreated every time they are used.
To prevent the risk of it being created incorrectly in different places, we
create it once and in the earliest moment possible: when the table is extracted.

Depends on D151989

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

show more ...