Re: [Dwarf-discuss] Representing captured `this` in C++ lambdas

On Wed, Apr 23, 2025 at 2:53 PM Kyle Huey wrote: > On Wed, Apr 23, 2025 at 2:20 PM David Blaikie wrote: > >> > >> Do you object to anything I proposed other than removing the > >> representation of the anonymous class compilers generate for lambdas? > > > > > > I'm not a /super/ fan of introduci

Re: [Dwarf-discuss] Representing captured `this` in C++ lambdas

> > Do you object to anything I proposed other than removing the > representation of the anonymous class compilers generate for lambdas? > I'm not a /super/ fan of introducing a bunch of locals in addition to the member descriptions - it'll be a bunch of extra DWARF that'd be nice to avoid if we c

Re: [Dwarf-discuss] Representing captured `this` in C++ lambdas

On Wed, Apr 16, 2025 at 8:59 AM Kyle Huey via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > This may be more of an implementation question than a spec question, > but this seems like the place to have the discussion regardless. > > C++ debuggers that support expression evaluation need

Re: [Dwarf-discuss] The new Version Scheme for V6.

On Fri, Mar 28, 2025 at 9:14 AM David Anderson wrote: > On 3/28/25 08:30, David Blaikie wrote: > > I believe the intent is that version numbers are able to be compared > > numerically. > > > > In any case, they are numbers per https://dwarfstd.org/ > > issues/210419.1.html

Re: [Dwarf-discuss] The new Version Scheme for V6.

I believe the intent is that version numbers are able to be compared numerically. In any case, they are numbers per https://dwarfstd.org/issues/210419.1.html - "A DW_AT_language_version attribute may be specified whose constant value is an integer code indicating the version of the source language

Re: [Dwarf-discuss] Alternative to 250130.1 (index valued DW_AT_object_pointer): LEB128 relative DIE offsets

On Mon, Feb 3, 2025 at 8:01 AM Paul Robinson wrote: > Also, fixed-size DIEs are much easier when quickly scanning for something; > you can derive the size of the DIE from the abbrev without having to look > at the DIE content. When you have variable-size values such as LEB128 then > you need to p

[Dwarf-discuss] Alternative to 250130.1 (index valued DW_AT_object_pointer): LEB128 relative DIE offsets

As an alternative to the indexed proposal in 250130.1, which proposes allowing a constant classed value for DW_AT_object_pointer, as an index into the formal parameters of the subprogram, I was wondering how folks would feel about something a bit different: What about a reference classed form that

Re: [Dwarf-discuss] [Proposal] DW_AT_object_pointer: clarify wording around implicit versus explicit object parameters

Yeah, I'm good either way - describing the artificiality of object_pointer as optional, or removing that entirely & leaving that up to consumers to use as needed. I think I'd lean towards removing the wording & leaving it up to users to decide what's artificial and what isn't. On Wed, Jan 22, 2025

Re: [Dwarf-discuss] DW_AT_discr_value improvement

+1, thanks for bringing this up, Tom - seems like just specing it as class "constant" would be fine. And in fact in table 7.5 it's already specified that way... So might just be a matter of removing the leb128 wording from the quoted area? @Cary Coutant could we get an issue filed for this? On M

Re: [Dwarf-discuss] [UPDATE] 240618.2 rnglists_base missing

On Mon, Jan 13, 2025 at 4:56 PM David Anderson wrote: > On 1/13/25 11:31, David Blaikie wrote: > > I still think the commentary on the indexes isn't quite right. They're > > separate from this issue - you'd still need the rnglists base, or have > > to assume that it's sizeof(header), to go that f

Re: [Dwarf-discuss] Does DWARF 5 specify which DW_LNCT content types are valid for directory entries?

On Tue, Jan 14, 2025 at 4:52 AM John DelSignore via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > In-line below... > On 1/13/25 20:10, David Anderson via Dwarf-discuss wrote: > > On 1/13/25 11:35, David Blaikie via Dwarf-discuss wrote: > > I guess Jon is refe

Re: [Dwarf-discuss] Does DWARF 5 specify which DW_LNCT content types are valid for directory entries?

On Mon, Jan 13, 2025 at 10:45 AM David Anderson via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > On 1/13/25 07:17, John DelSignore via Dwarf-discuss wrote: > > Hi, > > > > Section 6.2 (Line Number Information) of the DWARF 5 spec does not seem > to constrain which DW_LNCT content typ

Re: [Dwarf-discuss] [UPDATE] 240618.2 rnglists_base missing

I still think the commentary on the indexes isn't quite right. They're separate from this issue - you'd still need the rnglists base, or have to assume that it's sizeof(header), to go that far into the region described by the index. The index essentially makes a DWP look like a bunch of separate D

Re: [Dwarf-discuss] .debug_cu_index question

On Fri, Dec 20, 2024 at 9:36 AM David Anderson via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > > The examples of .debug_tu_index in DWARF5 Section F.2.3 > show the hash as computed by Type Signature Computation > Section 7.32 and referenced by DW_AT_LOCATION DW_FORM_ref_sig8. > do

Re: [Dwarf-discuss] Virtual Methods/Array Of Structs and Anonymous Structs

This is probably more of a question for the DWARF producer, like GCC, than the DWARF workgroup, but let's take a look anyway... Ah, OK, simplifying things down a bit. You've got this case: ``` struct t1 { typedef struct { } t2; #ifdef USE_VIRTUAL virtual void f1(); #endif }; t1::

Re: [Dwarf-discuss] bit-string

What sort of string-like behavior would one want on a bit-string? Seems like array would be the better fit to me... On Wed, Dec 18, 2024 at 9:03 AM pogo 59 via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > My first thought would be that DW_TAG_string_type with a one-bit base > type,

Re: [Dwarf-discuss] Proposal: Clarify DWARF Address Range Overlap Rules

On Thu, Dec 12, 2024 at 11:26 AM Ron Brender via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > >The current DWARF 5 specification's statement in Section 2.17.3 (p. 53, > line 15) that "Bounded range entries in a range list may not >overlap" is > overly restrictive and doesn't reflect

Re: [Dwarf-discuss] Proposal: Clarify DWARF Address Range Overlap Rules

On Thu, Dec 12, 2024 at 9:41 AM David Anderson via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > On 12/11/24 16:59, Alex via Dwarf-discuss wrote: > > ## Proposed Changes > > > > In Section 2.17 (Location Descriptions), replace the text on p. 53, line > 15: > > > > From: > > ``` > > Bo

Re: [Dwarf-discuss] Fwd: defaulting to C23 in GCC

+1. Best not to encourage use of things we haven't finished standardizing - though we made an explicit carveout for the language codes themselves. On Wed, Nov 20, 2024 at 9:49 AM pogo 59 via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Sorry, meant to reply-all. > > -- Forwa

Re: [Dwarf-discuss] Requirement to join the DWARF group

Thanks for taking an interest - and nice work on the DWARF parsing library! Joining the dwarf-discuss list is open to anyone and can be done here: https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss - though it's pretty low-traffic. If you're interested in joining the DWARF committee proper

Re: [Dwarf-discuss] Macros after "#include" does not show up DWARF

On Thu, Sep 12, 2024 at 11:08 AM Jakub Jelinek wrote: > On Thu, Sep 12, 2024 at 10:52:33AM -0700, David Blaikie via Dwarf-discuss > wrote: > > Looks probably like a bug in GCC and best discussed in their forum? > (clang > > seems to produce the macro in the macinf

Re: [Dwarf-discuss] Macros after "#include" does not show up DWARF

Looks probably like a bug in GCC and best discussed in their forum? (clang seems to produce the macro in the macinfo if you compile with `-fdebug-macro` (& you have to put some emitted entity (like a function definition) in the file before Clang will produce any debug info for the file)) On Wed, S

Re: [Dwarf-discuss] Question on Clang 18.1.8 and DW_IDX_parent

Some context: https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/44 https://github.com/llvm/llvm-project/pull/77457 Essentially clang/llvm produces DW_IDX_parent with DW_FORM_flag_present when the entry has a parent, but that parent isn't indexed (I think

Re: [Dwarf-discuss] Proposal/clarification: "inherited" subrange bounds

On Sat, Jul 27, 2024 at 10:50 PM Alexandre Oliva wrote: > On Jul 27, 2024, David Blaikie wrote: > > > If I'm following correctly, Alexandre - you're suggesting a situation > where > > an instance of a type, when it appears within a packed struct, may become > > smaller than it would otherwise be

Re: [Dwarf-discuss] Proposal/clarification: "inherited" subrange bounds

If I'm following correctly, Alexandre - you're suggesting a situation where an instance of a type, when it appears within a packed struct, may become smaller than it would otherwise be? (usually in C that's not the case - packing only changes the alignment of instances of the type - which may chang

Re: [Dwarf-discuss] Proposal: `DW_LNS_indirect_line`

On Sun, Jul 21, 2024 at 3:54 PM Jacob Young wrote: > > On 12/07/2024 19:04, David Blaikie wrote: > > > Thanks for all the context (I noticed you replied directly to me - are > > > you happy/OK having this discussion on the mailing list, rather than > > > in private? It'd help to keep all the hist

Re: [Dwarf-discuss] Proposal: `DW_LNS_indirect_line`

On Mon, Jul 8, 2024 at 2:18 PM David Blaikie wrote: > Hi Matthew, > > I'm looking into your issue & I have some broad questions: > > This seems like it'd speed up generics-heavy code, to be sure - though I > assume you hit a perf issue in some prototype tool already, that lead you > to this issue

Re: [Dwarf-discuss] Proposal: `DW_LNS_indirect_line`

Hi Matthew, I'm looking into your issue & I have some broad questions: This seems like it'd speed up generics-heavy code, to be sure - though I assume you hit a perf issue in some prototype tool already, that lead you to this issue? Do you have further details on the tooling you've prototyped/the

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

+Pavel Labath - since he's hit some issues related to this in lldb. Oh, yeah, I thought there was a case where we mangled the function parameter into the mangled name of a lambda - but I might've misremembered. The global variable case seems the closest to that and appears previously in this thre

Re: [Dwarf-discuss] DW_AT_base_types, loclists_base table F.1 incomplete

On Tue, May 28, 2024 at 12:38 PM David Anderson via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Issue: Clarification > > I cannot find any mention of these issues as open > in the DWARF6 issues list. > > Dwarf5, Appendix F, table F.1: > > DW_AT_loclists_base has a checkmark for co

Re: [Dwarf-discuss] Question on DW_AT_low_pc for "repeated" DW_TAG_subprogram

On Thu, May 16, 2024 at 1:05 PM Martin via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > On 16/05/2024 21:58, Martin via Dwarf-discuss wrote: > > > > > If there is code (with debug info) that uses a class/struct that is > > defined in a unit with debug info (or at least a base class i

Re: [Dwarf-discuss] strx use in debug_line table

On Thu, May 16, 2024 at 10:20 AM Mark Wielaard via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Hi, > > Section 6.2.4.1 Standard Content Descriptions under 1. DW_LNCT_path has > the following description on using DW_FORM_strx forms: > >In a .debug_line.dwo section, the forms DW_F

Re: [Dwarf-discuss] Question on DW_AT_low_pc for "repeated" DW_TAG_subprogram

On Thu, May 16, 2024 at 7:10 AM Martin via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > If a compiler adds a DW_TAG_subprogram for a routine from a different > compilation unit ... > Maybe because > - the other CU has no debug info > - The compiler does not support referencing cross

Re: [Dwarf-discuss] Question on "pascal property"

I'd be curious what compilers have been doing for Pascal for the last few decades - not exactly a new problem? But, yeah, might've all been getting by with extensions. On Wed, May 1, 2024 at 2:47 PM Adrian Prantl via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Just a quick very gen

Re: [Dwarf-discuss] Coroutines

Not that I'm aware of - there might be some existing features that are used by languages that've had coroutines longer than C++? Not sure. I think LLVM does produce some DWARF for coroutines, but I haven't looked at it/seen how viable it is/how much consumers would need to know really specific det

Re: [Dwarf-discuss] Proposal: Allow padding in all tables

Fair enough - alignment is mentioned in several cases, perhaps that could be omitted? If that's not usually the need/intent? On Wed, Jan 31, 2024 at 6:54 AM Robinson, Paul wrote: > This proposal is guidance for the producer, not the linker. The producer > needs this guidance specifically because

Re: [Dwarf-discuss] Proposal: Allow padding in all tables

Is anyone actually using this? In my experience linkers are generally concatenating these sections together with no extra padding/alignment. I'd rather not spec something that's not used/needed. I'm happy for consumers to be improved in the face of degenerate entries that might be created for padd

Re: [Dwarf-discuss] Enhancement: DWARF Extension Registry

On Fri, Dec 1, 2023 at 1:43 PM David Anderson via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > On 12/1/23 05:24, Ben Woodard via Dwarf-discuss wrote: > > My reasoning is that the reason why we are running out of vendor defined > > space is that within in the various vendor spaces the

Re: [Dwarf-discuss] Enhancement: DWARF Extension Registry

> > 5. Re 1.3.13: Blaming "reduced tool compatibility" on the skipability of > unknown constructs seems a huge and unjustified claim. I don't buy it. > > In most cases, I can see your point but in this case I cannot. To me this > seems obvious. > > Of course a consumer should be able to skip over s

Re: [Dwarf-discuss] Question: ETA?

Yeah - I mostly don't mind it taking as long as it takes. Eleanor - is there something you're particularly interested in/waiting for/etc? At least for myself, speaking as a clang/llvm debug info maintainer, I'd be happy to see DWARFv6 prototyped there (with a "no stability guarantee" caveat, becau

Re: [Dwarf-discuss] Question about section .debug_aranges

On Tue, Oct 24, 2023 at 6:09 AM Claudio Eterno via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Hi, I'm taking a look at docs. > On dwarf-2.0.0.pdf I see at "7.20 Address Range Table" > For what it's worth, I'd encourage you to consider other options for address lookup, as the plan

Re: [Dwarf-discuss] [DWARF5] .debug_names + fdebug-types-sections

On Mon, Oct 16, 2023 at 9:12 AM David Blaikie wrote: > > > On Mon, Oct 16, 2023 at 8:57 AM Alexander Yermolovich > wrote: > >> For background llvm discussion on how to implement it: >> >> https://discourse.llvm.org/t/debuginfo-dwarfv5-lld-debug-names-with-fdebug-type-sections/73445 >> >> Thanks

Re: [Dwarf-discuss] [DWARF5] .debug_names + fdebug-types-sections

On Mon, Oct 16, 2023 at 8:57 AM Alexander Yermolovich wrote: > For background llvm discussion on how to implement it: > > https://discourse.llvm.org/t/debuginfo-dwarfv5-lld-debug-names-with-fdebug-type-sections/73445 > > Thanks for explaining the issue, and proposing spec change. 🙂 > The question

[Dwarf-discuss] New Issue: Tombstoning TU entries in .debug_names

(derived from: https://lists.dwarfstd.org/mailman/private/dwarf-workgroup/2023-October/002444.html ) # Tombstoning TU entries in `.debug_names` ## Background Local type unit entries in `.debug_names` reference type units via their offset in the `.debug_info` section. Assuming a non-DWARF-aware

Re: [Dwarf-discuss] [DWARF5] .debug_names + fdebug-types-sections

On Fri, Sep 15, 2023 at 2:45 PM Alexander Yermolovich via Dwarf-discuss wrote: > > Hello > > I am trying to enable debug names acceleration table with > fdebug-types-sections in LLVM. One part I am not sure about is the local TU > list. It contains an offset into .debug_info section. All the ent

Re: [Dwarf-discuss] Ranges for DW_TAG_namespace

If what you're searching for could be encoded in the fast lookup tables (.debug_names) that could save you some parsing effort. Otherwise, if you're searching for an address and you have a lot of non-addressable DWARF, or really large CUs or something - I can see how namespace address ranges could

Re: [Dwarf-discuss] Sourceware infrastructure updates for Q3 2023

> But please don't sent HTML email. It will make DKIM verification of > your email impossible. Hmm - how does HTML email relate to/interfere with DKIM verification? -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Seeking a test program with a >4GB .debug_info section

On Fri, Apr 21, 2023 at 2:16 PM John DelSignore wrote: > > On 4/21/23 16:36, David Blaikie wrote: > > On Fri, Apr 21, 2023 at 12:44 PM John DelSignore > wrote: > >> Well, it took a long time to compile 5 CUs that contained your test code, >> and things were looking promising, but the link failed

Re: [Dwarf-discuss] Seeking a test program with a >4GB .debug_info section

On Fri, Apr 21, 2023 at 12:44 PM John DelSignore wrote: > Well, it took a long time to compile 5 CUs that contained your test code, > and things were looking promising, but the link failed: > > rocm2 42 04/21 15:14 /build/jdelsign/fatty % make > g++ -g -c fatty4.cxx -o fatty4.o > g++ -g -c fatty5

Re: [Dwarf-discuss] Seeking a test program with a >4GB .debug_info section

Oh, and I guess you could always make something even more artificial by hand - if you compile some random code with -g to assembly, you could then just pad out a .debug_info contribution with lots of zeros (there are some assembly directives for that, I think, but don't know assembly that well off

Re: [Dwarf-discuss] Seeking a test program with a >4GB .debug_info section

I /believe/ that Chromium (maybe specifically on ARM? not sure) may have hit/had problems with the 4GB limit - probably trivially if you build with clang but pass `-fstandalone-debug` which disables many type reduction/deduplication strategies. If you want something more standalone... this: #def

Re: [Dwarf-discuss] Tables which have a unit_length header field must be contiguous.

Yeah - agreed with this whole description & I'd feel comfortable with either of the proposed additions. On Wed, Mar 29, 2023 at 2:15 AM Keith Walker via Dwarf-discuss wrote: > > # Problem > > > > There is no statement if tables must be contiguous or if > > there can be padding between the tables.

Re: [Dwarf-discuss] ISSUE: CPU vector types.

> DW_AT[_GNU]_vector is best understood not as "a hardware vector register" but > rather as a marker that "this type is eligible to be passed in hardware > vector registers at function boundaries according to the platform ABI". My 2c would not be to describe these in terms of hardware/implementa

Re: [Dwarf-discuss] OTHER or arguably ENHANCEMENT: Logo

FWIW, I like the idea/reckon it's worth a revisit. I'd shy away from equipping the dwarves with weapons/combat imagery - maybe a smithy's hammer (or pickaxe) would be more suitable for tooling? (this sort of thing: https://www.kctool.com/picard-1c-blacksmiths-hammer-with-ash-handle-1800g/ - has a

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

Hmm - I guess one complication of only putting the mangling number on the type, is that you need the scope of the lambda too... which is tricky in this case: extern int i; int i = []{ return 3; }(); In this case, the lambda is mangled in the scope of the global variable `i`: i::{lambda()#1}::oper

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

Ping - any thoughts here? On Sun, Jul 24, 2022 at 9:08 PM David Blaikie wrote: > > 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 > t

Re: [Dwarf-Discuss] debug_aranges use and overhead

> > > > Greg > > > > > On Jun 14, 2022, at 1:10 PM, David Blaikie via Dwarf-Discuss > > > wrote: > > > > > > Given the discussion previously in this thread - does anyone have > > > particular objections to removing .debug_arang

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 -

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

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

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

[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] 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

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

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

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

[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] 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

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

[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] 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] 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] 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

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

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

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

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

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

+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

  1   2   >