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

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 5 13:51:22 PST 2024


dwblaikie wrote:

> > How's this compare to how we handle .debug_abbrevs? (perhaps we could be sharing some parsing infrastructure, the same as I'm suggesting/hoping we share some generation infrastructure - but even if not shared code, bringing two different implementations into alignment so they do/express things more similarly would be good)
> 
> The abbrevs currently makes a DWARFAbbreviationDeclarationSet which contains a `std::vector<DWARFAbbreviationDeclaration> Decls;` and it also maintains a value call `FirstAbbrCode` which is set to UINT32_MAX if the abbrevs were not indexed starting with some number. Compilers like to use 1 and the starting number. Then when we ask for an abbrev from the DWARFAbbreviationDeclarationSet, it sees is `FirstAbbrCode` is not set to UINT32_MAX, and if it isn't it returns a direct access using:
> 
> ```
> return &Decls[AbbrCode - FirstAbbrCode];
> ```
> 
> So O(1) lookups. Else it falls back to a very costly linear search. But most compilers emit the abbrevs with and index so this works well for 99% of the cases.
> 
> The DWARFDebugNames::Entry is quite different and stored in a hash map as the abbrev codes are not indexed.

I'm not sure I understand - what do you mean by "the abbrev codes are not indexed"? Because of LLVM's current output that uses the weird bit fiddling?

I'd consider that a bug/suboptimality, and I'd be fine with llvm-dwarfdump devolving to a linear search through abbrevs in the case where the abbrevs are not monotonically increasing.

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


More information about the llvm-commits mailing list