<div dir="ltr"><div dir="ltr">On Wed, Oct 27, 2021 at 6:29 AM <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><div class="gmail_quote"><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_-6536906177805431263WordSection1">
<p class="MsoNormal">Actually .debug_aranges is supposed to cover both code and (static/global) data.  DWARF v5 section 6.1.2, p.148 line 12 clearly says “text or data covered by some entry” so I’d say GCC has a bug there.</p></div></div></blockquote><div><br></div><div>Yep, that is what the spec says - but I'm curious if anyone's depending on this behavior/if that's a useful thing to do. If GCC's not doing it & hasn't forever, it seems unlikely anyone's relying on Clang doing that.</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"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-6536906177805431263WordSection1">
<p class="MsoNormal">That said… if there’s no DIE with the range, according to spec it can be omitted from .debug_aranges;</p></div></div></blockquote><div><br></div><div>I'm not sure that's the best thing for the spec to say, though - making it expensive to go searching through all the CUs for line table entries if that data wasn't communicated through CU DW_AT_ranges and aranges.<br><br>& I suspect the case of "line table describes instructions that aren't covered by any subprogram" isn't really a scenario the spec intended to cover in this wording - in which case we're a bit "off-spec" already, so maybe we can decide what that means?</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"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-6536906177805431263WordSection1"><p class="MsoNormal"> is that what the gmlt optimization does?</p></div></div></blockquote><div><br></div><div>It does.</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"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-6536906177805431263WordSection1">
<p class="MsoNormal">I think our backtrace printer might be assuming that .debug_aranges describes everything covered by .debug_line, which apparently is not the case if DIEs get omitted (or have their address ranges omitted).<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> Tuesday, October 26, 2021 7:36 PM<br>
<b>To:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>>; James Henderson <<a href="mailto:jh7370.2008@my.bristol.ac.uk" target="_blank">jh7370.2008@my.bristol.ac.uk</a>>; Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>>; Jonas Devlieghere <<a href="mailto:jdevlieghere@apple.com" target="_blank">jdevlieghere@apple.com</a>><br>
<b>Subject:</b> DWARF: Anyone using global variable addresses in .debug_aranges?<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">(I think we had some discussion about this a few years back, but can't seem to find it in my email)<br>
<br>
GCC doesn't put global variables/data into arranges, only functions/code - making arranges basically (entirely? so far as I know) the same as a CU's address range (high/low/ranges).<br>
<br>
Clang does put global variables in aranges. The whole arange content is driven by the emission of address attributes on DIEs.<br>
<br>
There's currently a bug (I introduced, someone else filed recently: <a href="https://urldefense.com/v3/__https:/bugs.llvm.org/show_bug.cgi?id=52187__;!!JmoZiZGBv3RvKRSx!tlBXtnd64BQMB7ocXsK4c4ix406Cn7chqYOkTvysFghb-mks3t0YDpVZj_TBzPTUmg$" target="_blank">
https://bugs.llvm.org/show_bug.cgi?id=52187</a>) in aranges with gmlt caused by the highly minimal form of gmlt I implemented a few years ago that skips subprogram DIEs for subprograms with no inlining (they have enough info in the line table+symbol table to
 do good backtraces, so we can save space by skipping the subprogram description). But this means no address attributes are emitted for these functions, so they don't end up in the aranges table.<br>
<br>
I think it might be simpler to fix this issue by making aranges be identical to CU ranges - this would be consistent with GCC's use of aranges (omitting globals) & reduce the chance of bugs of trying to keep two different lists in LLVM's implementation.<br>
<br>
What do folks think?<br>
<br>
(caveat: aranges are off by default in Clang because they seem redundant with CU ranges - I really don't understand why anyone's using them and we don't use them at Google... but bugs is bugs I guess)<u></u><u></u></p>
</div>
</div>
</div>
</div>

</blockquote></div></div>