<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2020 at 11:39 AM Robinson, Paul <<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">
<div class="gmail-m_-1990481942821586556WordSection1">
<p class="MsoNormal">I don’t know to what extent our debugger cares about non-.text entries. I can ask but those guys are slammed right now.</p></div></div></blockquote><div><br>Yeah, nothing vital - just curiosity.<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"><div class="gmail-m_-1990481942821586556WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> We care about debug-info size to the extent it can improve build (esp. link) times. I don’t have hard info about how our processes actually work, but I know we are smart about what sections get downloaded to the test console, and clearly
we try to be smart about loading debug sections by the debugger. This suggests to me that our tools are tuned to optimize remote/slow access to the image files, while Google’s tactic of copying the entire image to a developer’s machine before even getting
started is premised on debugging tools that aren’t really remote-filesystem-aware, with the traditional assumption of local/fast access to the image files.</p></div></div></blockquote><div><br>Certainly part of it - debugging hasn't been a high priority/common use case at Google for a long time (some changes recently, but not a massive shift in priorities/usage), so it's mostly about making adding debug info as unobtrusive as possible (as little overhead to compilation/linking), but without a lot of investment in/interference with the existing build/test/debugging tools. We also aren't usually dealing with a need to remote debug, so downloading the whole executable to the local machine for the debugger to run is fairly normal/reasonable - though split DWARF keeps most of the debug info out on the slow remote file system to be pulled in as needed. The last tricky one we might tackle after we tranistion to DWARFv5 might be the index sections (debug_names, gnu_pubnames, gdb_index, whatever you might call it/whatever we end up using) - it currently needs to be in the objects/linked executable (so the debugger doesn't have to pull down all the .dwo files to create such an index) but that adds a fair bit to the linker inputs, etc - so might end up with a 3rd intermediate file (.o, .dwo, .dwi(ndex)) or only a 3rd final output file (send the .o files to two different actions - a link action that ignores/skips the index sections, and an indexing sections that ignores everything other than the index sections).<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"><div class="gmail-m_-1990481942821586556WordSection1"><p class="MsoNormal"> This is all me speculating, I don’t actually know anything & am likely wrong about the reasoning, but
it fits the info I have.</p><p class="MsoNormal"><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> Monday, March 16, 2020 1:59 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> Dylan McKay <<a href="mailto:me@dylanmckay.io" target="_blank">me@dylanmckay.io</a>>; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm-dev] DWARF .debug_aranges data objects and address spaces<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Oh, and yeah - I'm all for turnaround time, though different situations put the costs for that in different places - for Google a distributed build means file sizes are important because they delay sending content between builders and from
the builders down to the developers machine.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Mar 16, 2020 at 10:56 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<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">
<div>
<div>
<p class="MsoNormal">On Mon, Mar 16, 2020 at 10:50 AM Robinson, Paul <<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">
<div>
<div>
<p class="MsoNormal">SCE tuning does turn on the .debug_aranges section. Our debugger team really cares about startup cost. Turnaround time in general is huge for our licensees, to the point where
we support edit-and-continue (minimal rebuild, live-patch the running process).<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
Ah, good to know! I'd be curious to know about the performance tradeoff when they're disabled if you ever happen to have data around that.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I guess a related question: Does SCE use the non-.text entries (or otherwise have an opinion on having them) in debug_aranges?<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">
<div>
<div>
<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> Monday, March 16, 2020 1:20 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> Dylan McKay <<a href="mailto:me@dylanmckay.io" target="_blank">me@dylanmckay.io</a>>;
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm-dev] DWARF .debug_aranges data objects and address spaces<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Mar 16, 2020 at 9:31 AM Robinson, Paul <<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:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal">With AVR being affected, upstreaming a patch to put segment selectors into .debug_aranges becomes completely reasonable. There would likely want to be a target hook somewhere to
return a value saying what size to use, with the default implementation returning zero.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">*nod* something along those lines<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <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:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"> > If the producer has put ranges on the CU it's not a lot of work - it's parsing one DIE & looking for a couple of attributes.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">It’s walking through all the CUs, picking up the associated abbrevs, trolling down the list of attributes… “not a lot” indeed, but not as trivial as running through a single section
linearly, which is what .debug_aranges gets you. I’ve been lectured by @clayborg on what consumers really want for performance gains.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
Sure enough - though I don't believe aranges is used by default on any target/platform LLVM supports, so this time/space tradeoff doesn't seem to have been important to any of them? <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:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"> > It's enough at least at Google for us to not use them & use CU ranges for the same purpose.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Google is much more seriously concerned about debug-info size than about debugger performance, IIRC. This is not universally the preferred tradeoff. Just sayin’.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:4.8pt">
<br>
Sure enough.<br>
<br>
I've just had a couple of people ask about aranges recently (~year or so) & when pressing a little further, using the CU's address ranges turned out to be sufficient for their needs without having to change Clang's defaults or have their users specify extra
flags to explicitly request them, etc.<br>
<br>
Out of curiosity/for data/usage/etc - does Sony use aranges? (changing the default when targeting SCE or the like)<br>
<br>
- Dave<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:5pt 0in 5pt 4.8pt">
<div>
<div>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<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:5pt 0in 5pt 4.8pt">
<p class="MsoNormal"> <u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote></div></div>