[llvm-dev] DWARF .debug_aranges data objects and address spaces

[Robinson, Paul via llvm-dev]

I don’t know to what extent our debugger cares about non-.text entries. I can ask but those guys are slammed right now.

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.  This is all me speculating, I don’t actually know anything & am likely wrong about the reasoning, but it fits the info I have.
--paulr

From: David Blaikie <dblaikie at gmail.com>
Sent: Monday, March 16, 2020 1:59 PM
To: Robinson, Paul <paul.robinson at sony.com>
Cc: Dylan McKay <me at dylanmckay.io>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] DWARF .debug_aranges data objects and address spaces

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.

On Mon, Mar 16, 2020 at 10:56 AM David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>> wrote:
On Mon, Mar 16, 2020 at 10:50 AM Robinson, Paul <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote:
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).

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.
I guess a related question: Does SCE use the non-.text entries (or otherwise have an opinion on having them) in debug_aranges?

--paulr

From: David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>>
Sent: Monday, March 16, 2020 1:20 PM
To: Robinson, Paul <paul.robinson at sony.com<mailto:paul.robinson at sony.com>>
Cc: Dylan McKay <me at dylanmckay.io<mailto:me at dylanmckay.io>>; llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] DWARF .debug_aranges data objects and address spaces

On Mon, Mar 16, 2020 at 9:31 AM Robinson, Paul <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote:
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.

*nod* something along those lines

 > 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.

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.

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?

 > It's enough at least at Google for us to not use them & use CU ranges for the same purpose.

Google is much more seriously concerned about debug-info size than about debugger performance, IIRC.  This is not universally the preferred tradeoff.  Just sayin’.

Sure enough.

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.

Out of curiosity/for data/usage/etc - does Sony use aranges? (changing the default when targeting SCE or the like)

- Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200316/883ff776/attachment.html>