<div dir="ltr">Hi David<div><br></div><div>I implemented some optimizations in the form of a specialized parser for fast AT_ranges scanning and performance is now comparable to lazy evaluation through .debug_aranges (only marginally worse assuming buffer cache warmed up). We've since shipped with these optimizations. I have to do some work in the same code base in March and will run a comparison then / share numbers here including after dropping buffers. If you would benefit from having them sooner, let me know and I'll make it happen.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 24, 2022 at 3:44 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.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 dir="ltr">Hey Samy - curious if you ever happened to end up getting further details here.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 9, 2021 at 1:05 PM Samy Al Bahra <<a href="mailto:sbahra@repnop.org" target="_blank">sbahra@repnop.org</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 dir="ltr"><div dir="ltr">Thanks for the detailed response David.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 9, 2021 at 2:52 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm not suggesting scanning all of .debug_info - only the CU DIE for<br>
DW_AT_ranges or high/low_pc, then skip to the next CU DIE (via the<br>
unit header's next unit offset).<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It sounded like CU ranges couldn't be used to build such an index at<br>
all/that your code used quite a different strategy in the absence of<br>
aranges? (rather than building the index from the CU ranges - somewhat<br>
slower I'm sure, but I wouldn't've thought (& am trying to understand<br>
if it is/why) so fundamentally slower that it wouldn't be the next<br>
fallback rather than skipping the index entirely or employing some<br>
more fundamentally different approach)</blockquote><div><br></div><div><div>This is still significantly less dense than aranges, involves more disk I/O and memory pressure. Let me see what optimizations I can implement here and get back to you with the results / what I came up with. This would be a better basis for apples to apples comparison.<br></div><div>  </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If you mean building ranges from all the DIEs deep inside a CU - yeah,<br>
that's going to be fundamentally slower in a bunch of ways that maybe<br>
I could see that would necessitate a totally different approach/that<br>
the index wouldn't make sense anymore (though I'd still like to<br>
understand it) - but I'm especially curious about the case where the<br>
CU DIE itself does have comprehensive address range information.<br></blockquote><div><br></div><div>Will report back on this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- Dave<br>
<br>
><br>
>><br>
>><br>
>>><br>
>>> (+ complexities Greg mentions later in the thread). In cases where we lack this, we use our own persistent cache which introduces unnecessary complexity. Now I am considering going as far as adding a multi-threaded indexer for cases where a persistent cache / build system modifications aren't an option (work to begin in the next week or two).<br>
>>><br>
>>> .debug_aranges would provide a lot of value to our users.<br>
>>><br>
>>> On Thu, Mar 11, 2021 at 3:48 PM David Blaikie via Dwarf-Discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org" target="_blank">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br>
>>>><br>
>>>> On Thu, Mar 11, 2021 at 5:48 AM <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<br>
>>>>><br>
>>>>> Hopefully not to side-track things too much... maybe wants its own<br>
>>>>> thread, if there's more to debate here.<br>
>>>><br>
>>>><br>
>>>> Yeah, how about we spin it off into another thread (done here)<br>
>>>><br>
>>>>><br>
>>>>> >> 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?<br>
>>>><br>
>>>><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.<br>
>>>><br>
>>>>> 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.<br>
>>>><br>
>>>><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>
>>>><br>
>>>> _______________________________________________<br>
>>>> Dwarf-Discuss mailing list<br>
>>>> <a href="mailto:Dwarf-Discuss@lists.dwarfstd.org" target="_blank">Dwarf-Discuss@lists.dwarfstd.org</a><br>
>>>> <a href="http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org" rel="noreferrer" target="_blank">http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Samy Al Bahra [<a href="http://repnop.org" rel="noreferrer" target="_blank">http://repnop.org</a>]<br>
><br>
><br>
><br>
> --<br>
> Samy Al Bahra [<a href="http://repnop.org" rel="noreferrer" target="_blank">http://repnop.org</a>]<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Samy Al Bahra [<a href="http://repnop.org" target="_blank">http://repnop.org</a>]</div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Samy Al Bahra [<a href="http://repnop.org" target="_blank">http://repnop.org</a>]</div>