[Dwarf-Discuss] debug_aranges use and overhead

[David Blaikie]

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
> like.
>
> Thanks,
>
> --paulr
>
>
>
> *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:
>
> <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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20220224/33ea9849/attachment.html>