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

[David Blaikie via llvm-dev]

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/c568ae94/attachment-0001.html>