This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by fdeazeve on Jun 5 2023, 6:45 AM.

Details

Summary

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

Diff Detail

Event Timeline

fdeazeve created this revision.Jun 5 2023, 6:45 AM
fdeazeve requested review of this revision.Jun 5 2023, 6:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 5 2023, 6:45 AM
fdeazeve updated this revision to Diff 528423.Jun 5 2023, 7:02 AM

Update base

aprantl accepted this revision.Jun 5 2023, 9:25 AM
aprantl added inline comments.
llvm/include/llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h
109

should this be default-initialized?

This revision is now accepted and ready to land.Jun 5 2023, 9:25 AM

Is this parsing code used for the standardized .debug_names too, and do we (LLVM itself, and maybe GCC too) generally produce fixed size records there? (not that I'm suggesting you should be the one to add support for variable sized records, but just to know if we should add a FIXME or other note about potential incompatibility/necessary improvement)

Is this parsing code used for the standardized .debug_names too

, and do we (LLVM itself, and maybe GCC too) generally produce fixed size records there?

Nope, this code is for apple tables only; the two kinds of tables only share a pure virtual class, but not any real implementation.

I want to look into how the debug_names work as well, but for now my goal is to bring LLVM to feature parity with the duplicate code found inside LLDB for apple tables, so that we can delete the (IMO) not as-good-looking code in LLDB :)

fdeazeve added inline comments.Jun 6 2023, 4:21 AM
llvm/include/llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h
109

I believe the design of this class is that it should not be used until IsValid is set to true, and IsValid is only set to true after all of its members are initialized.

We could clean this up by moving away from the declare(ctor)-then-initialize (extract) anti-pattern, instead making sure the constructor does all the way

JDevlieghere accepted this revision.Jun 6 2023, 9:19 AM

LGTM

llvm/include/llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h
109

+1: moving away from that would be great.

fdeazeve updated this revision to Diff 529684.Jun 8 2023, 11:20 AM

Fix clang format issue

This revision was landed with ongoing or failed builds.Jun 8 2023, 11:21 AM
This revision was automatically updated to reflect the committed changes.