Re: [Dwarf-Discuss] debug_names - what should go in ?

I'd say any case where a consumer couldn't actually rely on the table to do name resolution would be a bug - or at least something that needs to be seriously considered/discussed/figured out how the name table can be used in those situations. On Tue, Apr 10, 2018 at 8:33 AM Pavel Labath via Dwarf-

Re: [Dwarf-Discuss] debug_names - what should go in ?

Yep - sounds like it to me. I suppose, arguably, one could say that successful name lookups of things in the index can be fast, while lookups that fail, or find names not in the index may be slow - but that seems unacceptable to me (in many cases "slow" would be "prohibitively slow" especially the

Re: [Dwarf-Discuss] debug_names - what should go in ?

gt; > > > > For imported entities, I'd say if the imported entity would have > satisfied the criteria for inclusion in the index if it had been "inlined" > at the point where it was imported, then it ought to be in the index. > > > > --paulr > > > >

Re: [Dwarf-Discuss] The .debug_str_offsets section and libdwarf/dwarfdump

Does your example have a DW_AT_producer string by chance? On Sat, Apr 14, 2018 at 4:03 PM David Anderson via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > I've just pushed a new version of libdwarf/dwarfdump to sourceforge. > I mention this here because at least one compiler version

Re: [Dwarf-Discuss] The .debug_str_offsets section and libdwarf/dwarfdump

Adding a few folks working on Clang's DWARF5 functionality to see if this is a known bug (David Anderson mentioned it may've come from Clang r327823) and/or has been fixed. Perhaps a minimal example that produces this behavior/bug would be useful for David to have (not sure if he wants/needs it if

Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info

FWIW - if we're talking about assembly extensions, another one LLVM could use (it currently is one of the few things where Clang's integrated assembler can emit object code that can't be represented via textual assembly output) is the ability to express multiple line tables in a single assembly fil

Re: [Dwarf-Discuss] split dwarf, dwo, package files

On Wed, Jul 24, 2019 at 11:06 AM David Anderson via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > I've noticed that the documentation of split dwarf and the various CU > header > unit codes has a possible deficiency. > > For example, in sections F.2 and F.3 (examples, not the standard

Re: [Dwarf-Discuss] split dwarf, dwo, package files

On Thu, Jul 25, 2019 at 10:16 AM David Anderson wrote: > On 7/25/19 8:12 AM, David Blaikie wrote: > > > > No examples in F.2 F.3 show the corresponding compllation-unit > > header > > unit_type. Which leaves open the question of what the > > compilation-unit > > header uni

[Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content

(please add anyone who has a vested interest in Split DWARF in general and dwp in particular) tl;dr: How should DWARFv4 and DWARFv5 coexist in a DWP file: 1) Not at all (invalid/unsupported) 2) Single index table where the section indexes are subjective (look at the version of the referenced CU/TU

Re: [Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content

On Tue, Feb 25, 2020 at 11:41 AM Pavel Labath wrote: > Yeah, this sounds tricky, but it is actually good timing, because I > was just about to start working on DWP v5 in lldb. I was hoping that > would be an easy ride, but it looks like things will get complicated. > > On Tue, 25 Feb 2020 at 18:5

Re: [Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content

On Wed, Feb 26, 2020 at 6:29 AM Michael Eager wrote: > On 2/26/20 1:05 AM, Pavel Labath via Dwarf-Discuss wrote: > > The main question on my mind now is, what is the likely future > > direction of the DWARF spec -- if say DWARF v6 adds a new section, how > > will it handle mixed v5+v6 debug_cu_in

Re: [Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content

On Wed, Feb 26, 2020 at 1:05 AM Pavel Labath wrote: > On Tue, 25 Feb 2020 at 21:36, David Blaikie wrote: > > > > > > > > On Tue, Feb 25, 2020 at 11:41 AM Pavel Labath wrote: > >> > >> Yeah, this sounds tricky, but it is actually good timing, because I > >> was just about to start working on DWP

Re: [Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content

On Tue, Mar 10, 2020 at 1:31 AM Pavel Labath wrote: > On Mon, 9 Mar 2020 at 23:13, David Blaikie wrote: > > > > > > > > On Wed, Feb 26, 2020 at 1:05 AM Pavel Labath wrote: > >> Yes, the lack of an official extension space is unfortunate, but I > >> don't think this needs to be a blocker -- the

Re: [Dwarf-Discuss] Segment selectors for Harvard architectures

Not to derail this thread, but another thing that might be worth checking is: should debug_aranges include non-code addresses. GCC's don't, Clang's do. Sounds like Clang's correct, but GCC is sort of the defacto standard DWARF producer, so might be worth getting an authoritative statement/clarified

Re: [Dwarf-Discuss] Segment selectors for Harvard architectures

On Sun, Mar 29, 2020 at 2:56 PM Cary Coutant wrote: > > Not to derail this thread, but another thing that might be worth > checking is: should debug_aranges include non-code addresses. GCC's don't, > Clang's do. Sounds like Clang's correct, but GCC is sort of the defacto > standard DWARF producer

Re: [Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content

On Sun, Mar 29, 2020 at 3:44 PM Cary Coutant wrote: > >> > Yep - unless someone has significant objections my plan is currently: > >> > > >> > Emit a v5 index with extension/non-standard extra column indexes > (specifically: DW_SECT_LOC and 9 and DW_SECT_MACINFO at 10). I hope those > can at leas

Re: [Dwarf-Discuss] Discrepancy Between Implementation and Spec in Template Types

"quality of implementation" thing - but in general, even if a few bugs were fixed/improvements were made to both Clang and GCC, it's going to be hard/impossible to track certain things through templates in DWARF - for similar reasons that it's hard to provide diagnostic messages that describe types

Re: [Dwarf-Discuss] Selectively strip CUs from .debug_info?

Not aware of that specific tool - though debugger load time can be greatly improved by the use of some kind of debugger index. If their debugger of choice is GDB, then -ggnu-pubnames + -Wl,-gdb-index (with gold or lld) has made things pretty usable for my needs in LLVM development, and seems to sca

Re: [Dwarf-Discuss] Discrepancy Between Implementation and Spec in Template Types

On Fri, Apr 10, 2020 at 4:20 PM Jay Kamat wrote: > Ah, I see, that makes a lot of sense. However, I have a couple questions: > > > The DW_AT_type of v1 and the DW_AT_type of t2::m1 would need to > point > > to the same DIE, otherwise there would be much confusion about these > being > > different

Re: [Dwarf-Discuss] Usage of STRP forms in DWO files.

my 2c: "If STRP forms are allowed only in DWO files which cannot be combined into a DWP file, then a packaging utility should be smart enough to detect such input files and reject them. As there is no simple sign for that, the tool should analyze sections in input files to check if those forms are

Re: [Dwarf-Discuss] end_seq row at same address as previous row

I think LLVM produces some cases like this (maybe not at sequence end, but for other instructions (emit two copies without an advance PC between them (but maybe an advance line, etc) - in both cases, yeah, I'd consider this to be probably-valid-but-trivially-inefficient output. The way I think of r

Re: [Dwarf-Discuss] Segment selectors for the range list table.

Looking at how segment selectors work: DW_AT_segment: Applies to a DIE subtree, including any ranges, high/low pc, locations, labels, etc debug_range/loc (v4 and below): Doesn't seem to allow specifying segment variation - inherits from the segment given on the nearest parent DIE that refers to th

Re: [Dwarf-Discuss] Segment selectors for the range list table.

but a producer could choose which way to go there. (presumably if the AT_segment is there, you should interpret the addrx high_pc relative to that segment - assuming debug_addr has no segment selector in it - or perhaps it should go the other way and ignore the local AT_segment and only rely on whatev

Re: [Dwarf-Discuss] Segment selectors for the range list table.

On Wed, Jul 15, 2020 at 8:00 PM Xing GUO wrote: > Hi David, > > On 7/16/20, David Blaikie wrote: > > Looking at how segment selectors work: > > > > DW_AT_segment: Applies to a DIE subtree, including any ranges, high/low > pc, > > locations, labels, etc > > debug_range/loc (v4 and below): Doesn't

Re: [Dwarf-Discuss] modeling different address spaces

On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > (resending, this time without dropping the list from the cc: grump grump) > > > -Original Message- > > From: Dwarf-Discuss On Behalf > > Of Michael Eager via Dwarf-Discuss > > Se

Re: [Dwarf-Discuss] modeling different address spaces

On Thu, Jul 16, 2020 at 12:55 PM Michael Eager wrote: > On 7/16/20 11:51 AM, David Blaikie wrote: > > > > > > On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss > > The example that most often comes up is Harvard architectures. As it > > happens, I think it's nearly always

Re: [Dwarf-Discuss] Segment selectors for the range list table.

On Thu, Jul 16, 2020 at 1:07 PM Michael Eager wrote: > > Perhaps it's more like Paul was postulating - that the spec assumes code > > is in a code segment/doesn't need to be clarified. (but that gets a bit > > confused in debug_aranges - if it only is meant to contain code (not > > data), why doe

Re: [Dwarf-Discuss] Segment selectors for the range list table.

On Thu, Jul 16, 2020 at 2:05 PM Michael Eager wrote: > On 7/16/20 1:36 PM, David Blaikie wrote: > > > > > > On Thu, Jul 16, 2020 at 1:07 PM Michael Eager > > wrote: > > > > > Perhaps it's more like Paul was postulating - that the spec > > assumes code > >

Re: [Dwarf-Discuss] Segment selectors for the range list table.

On Thu, Jul 16, 2020 at 4:25 PM Michael Eager wrote: > On 7/16/20 2:57 PM, David Blaikie wrote: > > > > > > On Thu, Jul 16, 2020 at 2:05 PM Michael Eager > > > You appear to be starting with a counterfactual premise and using > that > > to postulate a problem where none exists. > > > > >

Re: [Dwarf-Discuss] Segment selectors for the range list table.

On Thu, Jul 16, 2020 at 6:35 PM Michael Eager wrote: > On 7/16/20 5:37 PM, David Blaikie wrote: > > > > > > On Thu, Jul 16, 2020 at 4:25 PM Michael Eager > > The language used to describe segmented addressing in DW_AT_segment > > reads to me like the same language used to describe segmented addr

Re: [Dwarf-Discuss] Segment selectors for the range list table.

. So now there's two ways a segment selector for an address could be specified - if you had a DW_TAG_subprogram with a DW_AT_low_pc using addrx into a debug_addr with a non-zero segment selector and the subprogram also had a DW_AT_segment, wonder which one's meant to win. Though mostly

[Dwarf-Discuss] DWARF for linker GC'd code

Paul filed an issue covering most of the details of this issue here: http://dwarfstd.org/ShowIssue.php?issue=200609.1 A quick summary: non-DWARF-aware linkers (ie: that aren't parsing all the DWARF and rewriting it during link time, which is expensive) have to resolve relocations in DWARF that re

Re: [Dwarf-Discuss] Question about DW_TAG_inlined_subroutine tags

On Thu, Jul 30, 2020 at 12:00 PM Greg Clayton via Dwarf-Discuss wrote: > > The LTO in clang creates some really interesting DWARF... One of the latest > things I discovered is DW_TAG_inlined_subroutine tags that are not contained > within a DW_TAG_subprogram. I am guessing the compiler/linker wa

Re: [Dwarf-Discuss] modeling different address spaces

On Fri, Aug 7, 2020 at 9:43 AM Pedro Alves via Dwarf-Discuss wrote: > > Hi there! > > On 7/31/20 1:17 AM, Tye, Tony via Dwarf-Discuss wrote: > > For optimized code involving multiple address spaces it is possible to run > > into cases where the location of a source language variable requires > >

Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

On Mon, Aug 31, 2020 at 10:33 AM David Anderson via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > I has occurred to me that simply restricting skeleton CUs > to use DW_FORM_string or DW_FORM_strp > would restore the unique meaning of DW_AT_str_offsets_base > to apply to the dwp (lett

Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

On Mon, Aug 31, 2020 at 8:22 PM David Anderson wrote: > On 8/31/20 1:03 PM, David Blaikie wrote: > > I'd rather go with LLVM's existing interpretation - that strx > > encodings used in .dwo do not attempt to use str_offsets in the skeleton. > > But I wouldn't mind adding a str_offsets_base to the

Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

On Tue, Sep 1, 2020 at 6:59 AM David Anderson wrote: > On 8/31/20 8:39 PM, David Blaikie wrote: > > Hmm... yeah. I guess LLVM implements rnglistx /rnglist_base the same > > as strx/str_offsets_base. Where it assumes that any *x encoding refers > > to entities in the .dwo, even in the absence of a

Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

On Tue, Sep 1, 2020 at 10:24 AM David Anderson wrote: > > On 8/31/20 8:39 PM, David Blaikie wrote: > > On Mon, Aug 31, 2020 at 8:22 PM David Anderson > > wrote: > > > > On 8/31/20 1:03 PM, David Blaikie wrote: > > > I'd rather go with LLVM's existing interpre

Re: [Dwarf-Discuss] .debug_addr entry plus offset

On Tue, Sep 15, 2020 at 10:13 AM Robinson, Paul via Dwarf-Discuss wrote: > > David Blaikie has brought this up with me (or in conversations that > I observed) a couple of times: Thanks for bringing this up! Not sure if I've raised this on dwarf-discuss specifically before.. ah, yeah, 3 years ago:

Re: [Dwarf-Discuss] .debug_addr entry plus offset

On Tue, Sep 15, 2020 at 2:47 PM Greg Clayton via Dwarf-Discuss wrote: > > One simple approach would be to be able to represent a DW_AT_low_pc with a > DW_FORM_data encoding just like the DW_AT_high_pc does when it is an offset > from the DW_AT_low_pc. I'm not sure this would catch all the desir

Re: [Dwarf-Discuss] HTML documentation for DWARF

I'd +1 that in general - probably mostly a question of who's going to do the initial work, and how much ongoing maintenance cost it'll incur. If you're volunteering to do the initial work, and it can be done so as to keep the ongoing maintenance cost low - perhaps the editor(s) will be open to it.

Re: [Dwarf-Discuss] Retrieving variables, function address using dwarf

On Fri, Mar 5, 2021 at 8:28 PM Archana Deshmukh via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Hello, > > I need to read the address of local variable, global variable, function > name and function arguments from the process. > > For global variables , I read the address "55b51afea

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

Frank: FWIW, gcc does not leave ABI-dependent gaps in the DWARF generated for function parameters. First class location lists are given, whether or not they are in the ABI-governed locations, or whether they've been moved somewhere else, or whether they've been optimized out so that a consumer mu

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Tue, Mar 9, 2021 at 11:29 AM Jakub Jelinek wrote: > On Tue, Mar 09, 2021 at 11:16:01AM -0800, David Blaikie via Dwarf-Discuss > wrote: > > void f1(int i) { } > > > > to include a DW_AT_location with fbreg, nothing about how the ABI > > represents 'i' -

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Tue, Mar 9, 2021 at 11:52 AM Jakub Jelinek wrote: > On Tue, Mar 09, 2021 at 11:43:54AM -0800, David Blaikie wrote: > > Thanks for the details! So in this case GCC changes the ABI of foo(int x, > > int y) to be equivalent to foo(int y) and the parameter description of > 'y' > > No, it is actual

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Tue, Mar 9, 2021 at 1:28 PM Paul Robinson via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > (re-sending because outlook omitted the group address) > > > -Original Message- > > From: Dwarf-Discuss On Behalf > > Of Jakub Jelinek via Dwarf-Discuss > > Sent: Tuesday, March 9,

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Tue, Mar 9, 2021 at 3:40 PM Jakub Jelinek wrote: > On Tue, Mar 09, 2021 at 03:22:35PM -0800, David Blaikie wrote: > > So, when the consumer evaluates DW_OP_GNU_parameter_ref, it handles it > > > similarly to DW_OP_entry_value, unwinds to caller if it can identify > it, > > > and just looks up

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 10:27 AM Jakub Jelinek via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Hi! > > We got a report today that GCC even for -gdwarf-5 -gsplit-dwarf uses > .debug_rnglists section + DW_AT_ranges + DW_AT_low_pc + DW_AT_rnglists_base > attributes in the DW_TAG_skelet

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 12:32 PM Cary Coutant wrote: > Location List and Range List Sections Improvement/Enhancement >> We > got a report today that GCC even for -gdwarf-5 -gsplit-dwarf uses > >> .debug_rnglists section + DW_AT_ranges + DW_AT_low_pc + > DW_AT_rnglists_base > >> attributes in the

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Wed, Mar 10, 2021 at 9:51 AM Michael Eager via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > On 3/9/21 7:05 AM, Andrew Cagney via Dwarf-Discuss wrote: > > Part of a typical Application Binary Interface is to specify the > > function calling convention. Several uses are: > > > > -

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 1:16 PM Cary Coutant wrote: > > But what about the DW_AT_ranges on the skeleton CU when using split > DWARF? > > > > Are you suggesting that both LLVM and GCC's emission is incorrect - and > that it's not possible to use rnglistx in the skeleton CU (instead you must > use

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Wed, Mar 10, 2021 at 1:21 PM Cary Coutant wrote: > > Speculation beyond the original question: > > Given that it's a pretty common/core feature of a debugger to call > functions, perhaps a start would be some way for the producer to > communicate, via DWARF, that it has changed the ABI of a fu

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 1:27 PM Jakub Jelinek wrote: > On Wed, Mar 10, 2021 at 01:16:24PM -0800, Cary Coutant wrote: > > > But what about the DW_AT_ranges on the skeleton CU when using split > DWARF? > > > > > > Are you suggesting that both LLVM and GCC's emission is incorrect - > and that it's n

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 2:36 PM Cary Coutant wrote: > On Wed, Mar 10, 2021 at 1:27 PM David Blaikie wrote: > > > > On Wed, Mar 10, 2021 at 1:16 PM Cary Coutant wrote: > >> > >> > But what about the DW_AT_ranges on the skeleton CU when using split > DWARF? > >> > > >> > Are you suggesting that b

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Wed, Mar 10, 2021 at 2:31 PM Michael Eager wrote: > On 3/10/21 1:28 PM, David Blaikie wrote: > > On Wed, Mar 10, 2021 at 1:21 PM Cary Coutant > > wrote: > > > > > Speculation beyond the original question: > > > Given that it's a pretty common/core feature

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 4:02 PM Cary Coutant wrote: > > > So in the end the logical thing to do when encountering a > > > DW_FORM_rnglistx in a split-unit, in order to support everybody, is > > > probably to go to the .debug_rnglists.dwo section, if there's one, > > > disregarding the (inherited)

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 9:38 PM Jakub Jelinek wrote: > On Wed, Mar 10, 2021 at 04:12:57PM -0800, David Blaikie via Dwarf-Discuss > wrote: > > On Wed, Mar 10, 2021 at 4:02 PM Cary Coutant wrote: > > > > > > > So in the end the logical thing to do when encounterin

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

+Mark in case he's got further context/perspective to share in the context of this thread One particular thing I'll pull out of the gdb-patches thread is: "But the rnglists (loclists) themselves can still use relocations. A large part of them is non-shared addresses, so using indexes (into the .d

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Thu, Mar 11, 2021 at 12:32 AM Jakub Jelinek wrote: > On Wed, Mar 10, 2021 at 10:07:27PM -0800, David Blaikie wrote: > > On Wed, Mar 10, 2021 at 9:38 PM Jakub Jelinek wrote: > > > > > On Wed, Mar 10, 2021 at 04:12:57PM -0800, David Blaikie via > Dwarf-Discuss >

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Thu, Mar 11, 2021 at 1:39 AM Jakub Jelinek wrote: > On Thu, Mar 11, 2021 at 01:05:06AM -0800, David Blaikie wrote: > > What's your take on: > > > > 1) Fixing GDB to handle GCC's current output. > > I don't know what GDB will do, it is up to the GDB people. > > > 2) Fixing GCC to produce someth

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Thu, Mar 11, 2021 at 2:55 AM Mark Wielaard wrote: > Hi David, > > On Thu, Mar 11, 2021 at 01:01:05AM -0800, David Blaikie wrote: > > +Mark in case he's got further context/perspective to share in the > context > > of this thread > > I haven't yet caught up on the mailinglist, but I think I und

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Thu, Mar 11, 2021 at 11:44 AM Jakub Jelinek wrote: > On Thu, Mar 11, 2021 at 11:30:05AM -0800, David Blaikie wrote: > > Thanks! - is this proposed as a DWARF extension? I thought I remembered > it > > 170427.1 I think. Note, what is emitted is different from what is being > proposed, the prob

[Dwarf-Discuss] debug_aranges use and overhead

On Thu, Mar 11, 2021 at 5:48 AM wrote: > Hopefully not to side-track things too much... maybe wants its own > thread, if there's more to debate here. > Yeah, how about we spin it off into another thread (done here) > >> For the case you suggested where it would be useful to keep the range > >>

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Thu, Mar 11, 2021 at 12:07 PM Mark Wielaard wrote: > Hi David, > > On Thu, Mar 11, 2021 at 11:30:05AM -0800, David Blaikie wrote: > > > > (I went to look a bit further and GCC's .debug_loclists.dwo but it > seems > > > > there's something about it that llvm-dwarfdump can't understand - it > on

Re: [Dwarf-Discuss] debug_aranges use and overhead

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

Re: [Dwarf-Discuss] debug_aranges use and overhead

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

Re: [Dwarf-Discuss] debug_aranges use and overhead

es unnecessary > complexity. Now I am considering going as far as adding a multi-threaded > indexer for cases where a persistent cache / build system modifications > aren't an option (work to begin in the next week or two). > > .debug_aranges would provide a lot of value to our users

Re: [Dwarf-Discuss] debug_aranges use and overhead

sense anymore (though I'd still like to understand it) - but I'm especially curious about the case where the CU DIE itself does have comprehensive address range information. - Dave > >> >> >>> >>> (+ complexities Greg mentions later in the thread). In cases w

Re: [Dwarf-Discuss] What to do with Pascal properties?

On Fri, May 28, 2021 at 8:29 AM Joost van der Sluis via Dwarf-Discuss wrote: > > Hi all, > > I am one of the Free Pascal developers and also work on a debugger, > aimed towards Free Pascal. > > Now in Pascal there are 'properties'. Maybe you know these from c# which > has something alike. Basicall

Re: [Dwarf-Discuss] What to do with Pascal properties?

On Sat, Jun 5, 2021 at 5:59 AM Joost van der Sluis via Dwarf-Discuss wrote: > > Op 03-06-2021 om 00:50 schreef David Blaikie via Dwarf-Discuss: > > On Fri, May 28, 2021 at 8:29 AM Joost van der Sluis via Dwarf-Discuss > > wrote: > >> Now in Pascal there are 'p

Re: [Dwarf-Discuss] How to map [[no_unique_address]] into DWARF

On Mon, Jun 7, 2021 at 10:58 AM Jan Kratochvil via Dwarf-Discuss wrote: > > Hi, > > clang-12 will create the same DWARF for class B with [[no_unique_address]] > either present or not. Despite that class C derived from B has different > layout depending on from which class B it gets derived Why is

Re: [Dwarf-Discuss] How to map [[no_unique_address]] into DWARF

Ah, in the sense that you want to be able to derive new types based on the DWARF? Fair enough. Raphael's suggestion seems reasonable to me. On Mon, Jun 7, 2021 at 11:20 AM Jan Kratochvil wrote: > > On Mon, 07 Jun 2021 20:11:16 +0200, David Blaikie via Dwarf-Discuss wrote: > &

Re: [Dwarf-Discuss] 170427.3 Extending loclists with common sublists

On Wed, Jun 30, 2021 at 5:37 AM Mark Wielaard via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Hi, > > We discussed 170427.3 Extending loclists with common sublists in the > last meeting. http://dwarfstd.org/ShowIssue.php?issue=170427.3 > > This issue was original part of a group of

[Dwarf-Discuss] Inconsistency of C++ member function qualifiers

C++ member functions can be qualified in a number of ways - classic CV (const and volatile) qualifiers, and since C++11, lvalue (&) and rvalue (&&) reference qualifiers. Details here: https://en.cppreference.com/w/cpp/language/member_functions A note on 5.10, page 127 says: "C++ const-volatile qu

Re: [Dwarf-Discuss] Inconsistency of C++ member function qualifiers

unctor is mutable or not. (so "std::any_invocable" is only callable when the object is non-const, but "std::any_invocable" is callable even on if it's a const object) > --paulr > > > > *From:* Dwarf-Discuss *On > Behalf Of *David Blaikie via Dwarf-D

[Dwarf-Discuss] string reduction techniques

Hey Todd, Just some details regarding the string reduction strategies I'm pursuing to address DWARF32 overflowing .debug_str.dwo/.debug_str_offsets.dwo sections in some large binaries at Google. So the extreme cases I'm dealing with are predominantly C++ Expression templates (in TensorFlow and Ei

Re: [Dwarf-Discuss] string reduction techniques

On Mon, Nov 1, 2021 at 1:52 PM Todd Allen wrote: > Dave, > > If I understand right: The space saving you're expecting is the > near-elimination > of DW_AT_name strings. If they are only simple names like "T" and "int", > they > can be placed into the string table once each, and it should be very

Re: [Dwarf-Discuss] string reduction techniques

On Mon, Nov 1, 2021 at 5:35 PM Cary Coutant wrote: > >> I can't be sure about this exponential growth. I don't have the data > to back it > >> up. But I will say, when we created DWARF64, I was skeptical that it > would be > >> needed during my career. And yet here we are... > > > > Yep, still

Re: [Dwarf-Discuss] string reduction techniques

On Mon, Nov 1, 2021 at 7:14 PM Greg Clayton via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > LLDB also uses mangled names. The clang compiler is our expression parser > and it always tries to resolve symbols during compilation/JIT and it > supplies mangled names when looking for func

Re: [Dwarf-Discuss] string reduction techniques

On Sun, Nov 7, 2021 at 12:36 PM Todd Allen wrote: > > Just spitballing an idea here, but would there be value in a new DW_FORM (or > two) that referenced the names from .strtab or .dynstr, instead of .debug_str? Yeah, something along those lines have crossed my mind too - I haven't looked into it

[Dwarf-Discuss] lambda (& other anonymous type) identification/naming

A rather common "quality of implementation" issue seems to be lambda naming. I came across this due to non-canonicalization of lambda names in template parameters depending on how a source file is named in Clang, and GCC's seem to be very ambiguous: $ cat tmp/lambda.h template void f1(T) { } s

Re: [Dwarf-Discuss] lambda (& other anonymous type) identification/naming

On Mon, Jan 24, 2022 at 5:37 PM Adrian Prantl wrote: > > > On Jan 23, 2022, at 2:53 PM, David Blaikie wrote: > > A rather common "quality of implementation" issue seems to be lambda > naming. > > I came across this due to non-canonicalization of lambda names in template > parameters depending on

Re: [Dwarf-Discuss] Producing .debug_names and questions about this lookup format

On Tue, Feb 1, 2022 at 3:45 PM Greg Clayton via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > I am in the process if writing a tool that can add .debug_names to a file > that contains DWARF but doesn’t have an accelerator table that is adequate > for debuggers to use. I was trying to

Re: [Dwarf-Discuss] clang -flto and LLVMgold.so

(might be easier to pick up from the thread where this came up or at least CC/to the folks you're referring to (though perhaps you did and that got stripped by the mailing list or something, not sure) - at least for me, I have highlights for emails addressed to me that helps prioritizing/knowing if

Re: [Dwarf-Discuss] debug_aranges use and overhead

own persistent cache which introduces unnecessary >> complexity. Now I am considering going as far as adding a multi-threaded >> indexer for cases where a persistent cache / build system modifications >> aren't an option (work to begin in the next week or two). &g

Re: [Dwarf-Discuss] debug_aranges use and overhead

understand it) - but I'm especially curious about the case where the >>>> CU DIE itself does have comprehensive address range information. >>>> >>> >>> Will report back on this. >>> >>> >>>> >>>> - Dave >>

Re: [Dwarf-Discuss] debug_aranges use and overhead

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

Re: [Dwarf-Discuss] debug_aranges use and overhead

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

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > > > On Feb 28, 2022, at 5:49 AM, Ron Louzon via Dwarf-Discuss < > dwarf-discuss@lists.dwarfstd.org> wrote: > > I have an application which uses DwarfLib to extract type information from > d

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

On Mon, Feb 28, 2022 at 2:58 PM Michael Eager wrote: > On 2/28/22 13:11, David Blaikie via Dwarf-Discuss wrote: > > On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss > > You could choose to not show this, but I find it is often easier to > > show thi

Re: [Dwarf-Discuss] How to generate DWARF info for a template alias to a raw pointer

On Fri, May 6, 2022 at 10:08 AM Robinson, Paul via Dwarf-Discuss wrote: > > > Could someone help to point out what kind of DWARF info should > > be generated for below c++ source? Thanks > > > > ``` > > template > > using ptr = T*; > > > > ptr abc; > > ``` > > > > We declare a template alias here

[Dwarf-Discuss] CU-local types

Looks like gdb and lldb both have issues with C++ local types (either types defined in anonymous namespaces, or otherwise localized - eg: a non-local template with a local type or variable in one of its parameters). GDB correctly associates directly referenced types (eg: the type of a variable does

Re: [Dwarf-Discuss] CU-local types

On Wed, May 18, 2022 at 4:16 AM Robinson, Paul wrote: > > > Looks like gdb and lldb both have issues with C++ local types (either > > types defined in anonymous namespaces, or otherwise localized - eg: a > > non-local template with a local type or variable in one of its > > parameters). > > ... >

Re: [Dwarf-Discuss] CU-local types

On Wed, May 18, 2022 at 9:53 AM David Blaikie wrote: > > On Wed, May 18, 2022 at 4:16 AM Robinson, Paul wrote: > > > > > Looks like gdb and lldb both have issues with C++ local types (either > > > types defined in anonymous namespaces, or otherwise localized - eg: a > > > non-local template with

Re: [Dwarf-Discuss] debug_aranges use and overhead

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

Re: [Dwarf-Discuss] CU-local types

than "t" (& so then you'll get "t" entries for "t" and "t", etc... and have to disambiguate them) But that's, I think, a different topic from the one this thread is about - how to identify which types are CU-local and which types are not. M

Re: [Dwarf-Discuss] lambda (& other anonymous type) identification/naming

Looks like https://reviews.llvm.org/D122766 (-ffile-reproducible) might solve my immediate issues in clang, but I think we should still consider moving to a more canonical naming of lambdas that, necessarily, doesn't include the file name (unfortunately). Probably has to include the lambda numberin

Re: [Dwarf-Discuss] DWARF bitness in loclists, etc

On Sun, Jun 26, 2022 at 2:24 PM Vsevolod Alekseyev via Dwarf-Discuss wrote: > > Makes sense, thank you. It's enough for me to go with as far as parsing is > concerned. > > That said, why bother with the bitness indicator in the ...lists sections at > all? I can't imagine parsing them from top to

Re: [Dwarf-Discuss] lambda (& other anonymous type) identification/naming

Ping on this thread - would love to hear what ideas folks have for addressing the naming of anonymous types (enums, structs/classes, and lambdas) - especially if it'd make it easier to go back/forth between the DW_AT_name of a template with an unnamed type as a parameter and the actual DIEs describ

Re: [Dwarf-Discuss] debug_aranges use and overhead

h 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 previously in this thread -

  1   2   >