<div dir="ltr">Tom - any chance you've had/could take a brief look at this issue?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 11, 2021 at 1:12 PM <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-5637735990147223832WordSection1">
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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. 
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’ll have to think about what a “modern” .debug_aranges might want to look like.<u></u><u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">--paulr<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> <br>
<b>Sent:</b> Thursday, March 11, 2021 3:48 PM<br>
<b>To:</b> Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>><br>
<b>Cc:</b> Cary Coutant <<a href="mailto:ccoutant@gmail.com" target="_blank">ccoutant@gmail.com</a>>; DWARF Discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org" target="_blank">dwarf-discuss@lists.dwarfstd.org</a>><br>
<b>Subject:</b> debug_aranges use and overhead<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Mar 11, 2021 at 5:48 AM <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<u></u><u></u></p>
</div>
<div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Hopefully not to side-track things too much... maybe wants its own<br>
thread, if there's more to debate here.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><br>
Yeah, how about we spin it off into another thread (done here)<br>
 <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">>> For the case you suggested where it would be useful to keep the range<br>
>> list for the CU in the .o file, I think .debug_aranges is what you're<br>
>> looking for.<br>
><br>
> aranges has been off by default in LLVM for a while - it adds a lot of<br>
> overhead (doesn't have all the nice rnglist encodings for instance -<br>
> nor can it use debug_addr, and if it did it'd still be duplicate with<br>
> the CU ranges wherever they were).<br>
<br>
Did you want to file an issue to improve how .debug_aranges works?<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
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.<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Complaining that it duplicates CU ranges is missing the point, though;<br>
it's an index, like .debug_names, of course it duplicates other info.<br>
If you want to suggest an improved index, like we did with .debug_names,<br>
that would be great too.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><br>
.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).<br>
<br>
.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.<br>
<br>
Do you have numbers on the benefits of .debug_aranges compared to parsing the ranges from CU DIEs?<br>
<br>
(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)<br>
<br>
Roughly, a modern debug_aranges to me would look something like:<br>
<br>
<length><br>
<version><br>
<CU sec_offset><br>
<addr_base><br>
<rnglist sec_offset><br>
<br>
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.<br>
 <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>

</blockquote></div>