Tom Russell could perhaps speak to this better, but my understanding is that our debugger guys like having .debug_aranges, because parsing the CU DIE does take that extra effort. I am unfamiliar with their code so I have to take their word on it. But I can certainly imagine that probing hundreds to thousands of CUs in order to collect range information with lengthy range lists would be more expensive than running through a comparatively compact .debug_aranges list. If Tom tells me I’m wrong, well, wouldn’t be the first time.
One thing we have encountered (see issue 210113.1) is that when we’ve done dead-stripping, .debug_aranges entries (one per function, typically, because -ffunction-sections) can end up pointing to nothing. In our proprietary linker I believe we compress/rewrite .debug_aranges to minimize the number of entries, which by coincidence ends up producing a conforming aranges list; LLD doesn’t do that, which means it produces a non-conforming list (with zero-length entries), hence the issue. I’ll have to think about what a “modern” .debug_aranges might want to look like. Thanks, --paulr From: David Blaikie <dblai...@gmail.com> Sent: Thursday, March 11, 2021 3:48 PM To: Robinson, Paul <paul.robin...@sony.com> Cc: Cary Coutant <ccout...@gmail.com>; DWARF Discuss <dwarf-discuss@lists.dwarfstd.org> Subject: debug_aranges use and overhead On Thu, Mar 11, 2021 at 5:48 AM <paul.robin...@sony.com<mailto:paul.robin...@sony.com>> wrote: Hopefully not to side-track things too much... maybe wants its own thread, if there's more to debate here. Yeah, how about we spin it off into another thread (done here) >> For the case you suggested where it would be useful to keep the range >> list for the CU in the .o file, I think .debug_aranges is what you're >> looking for. > > aranges has been off by default in LLVM for a while - it adds a lot of > overhead (doesn't have all the nice rnglist encodings for instance - > nor can it use debug_addr, and if it did it'd still be duplicate with > the CU ranges wherever they were). Did you want to file an issue to improve how .debug_aranges works? I don't currently understand the value it provides, and I at least don't have a use case for it, so I'm not sure I'd be the best person to advocate/drive that work. Complaining that it duplicates CU ranges is missing the point, though; it's an index, like .debug_names, of course it duplicates other info. If you want to suggest an improved index, like we did with .debug_names, that would be great too. .debug_names is quite different though - it collects information from across the DIE tree - information that is expensive to otherwise gather (walking the whole DIE tree). .debug_aranges is not like that for most producers (producers that do include the address ranges on the CU DIE) - the data is readily available immediately on the CU. That does involve reading some of .debug_abbrev, and interpreting a handful of attributes - but at least for the use cases I'm aware of, that overhead isn't worth the size increase. Do you have numbers on the benefits of .debug_aranges compared to parsing the ranges from CU DIEs? (one possible issue: the CU doesn't /have/ to contain low/high/ranges if its children DIEs contain addresses - having that as a guarantee, or some preferred way of encoding zero length (high/low of 0 would be acceptable, I guess) would be nice & make it cheap to skip over CUs that don't have any address ranges) Roughly, a modern debug_aranges to me would look something like: <length> <version> <CU sec_offset> <addr_base> <rnglist sec_offset> So it could fully re-use the rnglist encoding. If this was going to be as compact as possible, it'd need to be configurable which encodings it uses - ranges V high/low, addrx V addr - at which point it'd probably look like a small DIE with an inline abbrev (similar to the way DWARFv5 encodes the file and directory entries now, and how debug_names is self-describing) - at which point it looks to me a lot like parsing the CU DIEs.
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
