[Dwarf-Discuss] debug_aranges use and overhead

[paul.robinson@sony.com]

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@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<mailto: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/c5fcf615/attachment-0001.html>