[Dwarf-Discuss] debug_aranges use and overhead
dblaikie at gmail.com
Thu Feb 24 14:39:22 PST 2022
Tom - any chance you've had/could take a brief look at this issue?
On Thu, Mar 11, 2021 at 1:12 PM <paul.robinson at sony.com> wrote:
> 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
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* Thursday, March 11, 2021 3:48 PM
> *To:* Robinson, Paul <paul.robinson at sony.com>
> *Cc:* Cary Coutant <ccoutant at gmail.com>; DWARF Discuss <
> dwarf-discuss at lists.dwarfstd.org>
> *Subject:* debug_aranges use and overhead
> On Thu, Mar 11, 2021 at 5:48 AM <paul.robinson at 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:
> <CU sec_offset>
> <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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dwarf-Discuss