Here's the posted issue: https://dwarfstd.org/ShowIssue.php?issue=220724.1
On Sun, Jul 24, 2022 at 10:56 PM David Blaikie wrote:
>
> Posted an issue to the dwarfstd.org to propose removing
> .debug_aranges, will follow up with a link here once it's
> accepted/posted publicly.
>
> On Tue, Jun 14,
Posted an issue to the dwarfstd.org to propose removing
.debug_aranges, will follow up with a link here once it's
accepted/posted publicly.
On Tue, Jun 14, 2022 at 2:02 PM Greg Clayton wrote:
>
> As long as there is a DW_AT_ranges on the CU the is complete, that is good
> enough for LLDB. No one
As long as there is a DW_AT_ranges on the CU the is complete, that is good
enough for LLDB. No one seems to consistently emit .debug_aranges these days so
we definitely don't rely on it.
Greg
> On Jun 14, 2022, at 1:10 PM, David Blaikie via Dwarf-Discuss
> wrote:
>
> Given the discussion pre
At this point, performance is good enough for our use-case, no qualms from
me.
On Tue, Jun 14, 2022 at 4:10 PM David Blaikie via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Given the discussion previously in this thread - does anyone have
> particular objections to removing .debug
Given the discussion previously in this thread - does anyone have
particular objections to removing .debug_aranges? (in favor of/perhaps
with specific wording that /requires/ CU level ranges to be specified
(ie: it's not acceptable to have a subprogram with non-empty range in
a CU which doesn't cov
On Fri, Feb 25, 2022 at 1:23 AM tom.russ...@sony.com
wrote:
> Hi David,
>
>
>
> We don’t use .debug_aranges in our debugger (and, to my knowledge, never
> have). Our strategy is to up front load all the debug information and
> convert it to our internal format. For that reason, the sections relat
Hi David,
We don’t use .debug_aranges in our debugger (and, to my knowledge, never have).
Our strategy is to up front load all the debug information and convert it to
our internal format. For that reason, the sections relating to accelerated
access are not useful for us as we’ll be visiting & i
Tom - any chance you've had/could take a brief look at this issue?
On Thu, Mar 11, 2021 at 1:12 PM wrote:
> Tom Russell could perhaps speak to this better, but my understanding is
> that our debugger guys like having .debug_aranges, because parsing the CU
> DIE does take that extra effort. I am
On Thu, Feb 24, 2022 at 2:24 PM Samy Al Bahra wrote:
> Hi David
>
> I implemented some optimizations in the form of a specialized parser for
> fast AT_ranges scanning and performance is now comparable to lazy
> evaluation through .debug_aranges (only marginally worse assuming buffer
> cache warme
Hi David
I implemented some optimizations in the form of a specialized parser for
fast AT_ranges scanning and performance is now comparable to lazy
evaluation through .debug_aranges (only marginally worse assuming buffer
cache warmed up). We've since shipped with these optimizations. I have to
do
Hey Samy - curious if you ever happened to end up getting further details
here.
On Fri, Apr 9, 2021 at 1:05 PM Samy Al Bahra wrote:
> Thanks for the detailed response David.
>
> On Fri, Apr 9, 2021 at 2:52 PM David Blaikie wrote:
>
>> I'm not suggesting scanning all of .debug_info - only the CU
Thanks for the detailed response David.
On Fri, Apr 9, 2021 at 2:52 PM David Blaikie wrote:
> I'm not suggesting scanning all of .debug_info - only the CU DIE for
> DW_AT_ranges or high/low_pc, then skip to the next CU DIE (via the
> unit header's next unit offset).
>
> It sounded like CU range
On Fri, Apr 9, 2021 at 11:13 AM Samy Al Bahra wrote:
>
> Responses inline.
>
> On Fri, Mar 19, 2021 at 9:59 PM David Blaikie wrote:
>>
>> On Fri, Mar 19, 2021 at 9:34 AM Samy Al Bahra wrote:
>
>
> [...]
>
>>>
>>> This is quite old (excuse the formatting) but numbers are here:
>>> https://engine
Responses inline.
On Fri, Mar 19, 2021 at 9:59 PM David Blaikie wrote:
> On Fri, Mar 19, 2021 at 9:34 AM Samy Al Bahra wrote:
>
[...]
> This is quite old (excuse the formatting) but numbers are here:
>> https://engineering.backtrace.io/2014-09-15-bt-lightweight-backtrace-tool/
>> , search fo
> On Mar 19, 2021, at 11:22 AM, Frank Ch. Eigler wrote:
>
> Hi -
>
>> We have seen GSYM files up to 20x smaller than the DWARF file, which
>> to be fair often includes all other sections (.text, .data, etc).
>
> What information is lost?
GSYM does not contain:
- variable information (locals
On Fri, Mar 19, 2021 at 9:34 AM Samy Al Bahra wrote:
> Hi David,
>
> Sorry I'm a bit late to the game.
>
No worries at all - appreciate any/all perspectives/data here, for sure!
> On the value of having .debug_aranges and the performance impact:
>
> Our debugger was designed for performance an
Hi Greg,
We currently use a similar format for server-side symbolication where
static analysis is not being performed (for example, when we ingest core
dumps / minidump directly on the backend) with similar design goals, it was
inspired by Breakpad's sym and includes similar extensions for inline
Hi -
> We have seen GSYM files up to 20x smaller than the DWARF file, which
> to be fair often includes all other sections (.text, .data, etc).
What information is lost?
- FChE
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lis
> On Mar 19, 2021, at 9:33 AM, Samy Al Bahra via Dwarf-Discuss
> wrote:
>
> Hi David,
>
> Sorry I'm a bit late to the game. On the value of having .debug_aranges and
> the performance impact:
>
> Our debugger was designed for performance and does end to end lazy evaluation
> (down to the D
Hi David,
Sorry I'm a bit late to the game. On the value of having .debug_aranges and
the performance impact:
Our debugger was designed for performance and does end to end lazy
evaluation (down to the DIE). This is quite old (excuse the formatting) but
numbers are here:
https://engineering.backtr
Yeah, we talked some last year about formalizing this more into the -1
tombstone - I thought maybe Paul had proposed that for standardization, though
at a glance I don't see the proposal. It's probably somewhere there.
200609.1 Reserve an address value for “not present”
--paulr
On Thu, Mar 11, 2021 at 4:29 PM Greg Clayton wrote:
>
>
> On Mar 11, 2021, at 1:12 PM, Paul Robinson via Dwarf-Discuss <
> dwarf-discuss@lists.dwarfstd.org> wrote:
>
> Tom Russell could perhaps speak to this better, but my understanding is
> that our debugger guys like having .debug_aranges, beca
> On Mar 11, 2021, at 1:12 PM, Paul Robinson via Dwarf-Discuss
> wrote:
>
> Tom Russell could perhaps speak to this better, but my understanding is that
> our debugger guys like having .debug_aranges, because parsing the CU DIE does
> take that extra effort. I am unfamiliar with their code
On Thu, Mar 11, 2021 at 1:12 PM wrote:
> Tom Russell could perhaps speak to this better, but my understanding is
> that our debugger guys like having .debug_aranges, because parsing the CU
> DIE does take that extra effort. I am unfamiliar with their code so I have
> to take their word on it. B
Tom Russell could perhaps speak to this better, but my understanding is that
our debugger guys like having .debug_aranges, because parsing the CU DIE does
take that extra effort. I am unfamiliar with their code so I have to take
their word on it. But I can certainly imagine that probing hundre
25 matches
Mail list logo
