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

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

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

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

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

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,

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

[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

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

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

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

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:

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

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

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

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 >

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_aranges? (in fav

Re: [Dwarf-Discuss] debug_aranges use and overhead

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

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

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

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

Re: [Dwarf-Discuss] CU-local types

"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. Maybe the template ac

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

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

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

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 >

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

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

Re: [Dwarf-Discuss] debug_aranges use and overhead

gt;>>> CU DIE itself does have comprehensive address range information. >>>> >>> >>> Will report back on this. >>> >>> >>>> >>>> - Dave >>>> >>>> > >>>> >> >>>>

Re: [Dwarf-Discuss] debug_aranges use and overhead

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

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

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

[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) { }

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

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

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,

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

[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

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

table 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-Discuss > *Sent:*

[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

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

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

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 '

Re: [Dwarf-Discuss] debug_aranges use and overhead

ous about the case where the CU DIE itself does have comprehensive address range information. - Dave > >> >> >>> >>> (+ complexities Greg mentions later in the thread). In cases where we lack >>> this, we use our own persistent cache which intro

Re: [Dwarf-Discuss] debug_aranges use and overhead

ing 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. > > On Thu, Mar 11, 2021 at 3:48 PM David Bla

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,

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.

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 >

[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

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

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

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

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 encounte

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

[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: [Dwarf-Discuss] Segment selectors for the range list table.

am 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 my point was: since debug_addr entries can have segment selectors, then debug_rnglists can have different segments for

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

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

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

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

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

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

hich 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 whatever segment is in debug_addr) >

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

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

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

  1   2   >