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

[David Blaikie via llvm-dev]

On Mon, Mar 16, 2020 at 11:39 AM Robinson, Paul <paul.robinson at sony.com>
wrote:

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

Yeah, nothing vital - just curiosity.


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

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


>   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> wrote:
>
> On Mon, Mar 16, 2020 at 10:50 AM Robinson, Paul <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>
> *Sent:* Monday, March 16, 2020 1:20 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
>
>
>
> On Mon, Mar 16, 2020 at 9:31 AM Robinson, Paul <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/0ba17ad1/attachment.html>