[Dwarf-Discuss] debug_aranges use and overhead

[David Blaikie]

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.
>

Yeah, I'd be curious to know more, for sure. Might resort to writing the
smallest DWARF parser to, say, handle address queries using debug_aranges
or CU ranges for comparison.


> 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.
>

Yeah, it might be that it's more practical to fixup debug_aranges for dead
stripping than it is to fixup debug_rnglists (I mean, it is, for sure
easier to do) - and that fixing up likely makes the aranges much more
compact and thus cheaper to use/parse, which might be part of the
motivation for them.

One of the things I've thought about in that direction would be a flag on
debug_rnglists contributions (a bit in the header) that says "all rnglists
in here are referenced /only/ by rnglistx" - that way a linker could know
that it could rewrite the whole rnglist contribution and so long as it
fixed up the offset table at the start to adjust for any shrinking or
removed rnglists, it would still be correct. Hmm, now that I think about it
-such an attribute wouldn't be needed, necessarily - if the linker was
willing to adjust how relocations referring to the debug_rnglist section
were applied as things shifted around. (& you've got to use relocations
anyway, if you're not using rnglistx)


> 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/20210311/d6aace64/attachment-0001.html>