[llvm] [LLVM][DWARF] Change .debug_names abbrev to be an index (PR #81200)

Alexander Yermolovich via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 8 15:03:57 PST 2024


ayermolo wrote:

I put structs and helper method into 8ui9

> > > This allows for tools like LLDB to access it in constant time.
> > 
> > 
> > I don't think this is true: the spec does not require the table to be monotonically increasing. So LLDB either needs to first check if all entries are neatly organized, or just build a map anyway.
> 
> At least the way libDebugInfoDWARF does it is that it does check - it parses all the abbrevs, but rather than creating a map - it keeps track of whether the abbrev numbers are monotonically increasing and records the first one - and if they are it does the lookup in O(1), and if they aren't it does a linear search.
> 
> Yes, a map would be O(1) in both cases, with higher constant factors and memory overhead - but given this approach has worked for some time for abbrevs, I'd like to use it for debug_name abbrevs too. And the sooner we switch to it for both producer and consumers we control, the more likely we are to encourage this as a fairly simple way to do these lookups quickly. (not that the performance of abbrev lookups is likely to be critical, especially in .debug_names when there are probably only a handful of them anyway)
> 
> Looks like LLDB maybe uses the `llvm::DWARFAbbreviationDeclarationSet` which uses this strategy implemented here:
> 
> https://github.com/llvm/llvm-project/blob/f7201505a6ec7a0f904d2f09cece5c770058a991/llvm/lib/DebugInfo/DWARF/DWARFDebugAbbrev.cpp#L62
> 
> (`FirstAbbrevCode` is set to the sentinel `UINT32_MAX` if the abbrev numbers are not monotonically increasing, and a linear search is used - otherwise a direct index is used, after bounds checking)
> > The big motivation for this patch are the space savings: the debug_names section will be much smaller as most abbreviations now fit in 1 byte
> 
> That's nice too, for sure.

Right this. Phrased it poorly. 

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


More information about the llvm-commits mailing list