Re: [Dwarf-Discuss] Line table "no-op" sequence

On Wed, Apr 25, 2018 at 11:38 AM, wrote: >> One technique you haven't mentioned is to stretch out LEB128 numbers >> with extra 0x80's. > > Yeah, I kind of don't like abusing the LEB format like that. Maybe > for one or two bytes, but not arbitrarily long strings (as you

Re: [Dwarf-Discuss] Line table "no-op" sequence

> Recently I had a chat with one of the linker developers on my team. > He was trying to work out how to insert what would effectively be a > no-op sequence into the line table. > > One reason to do this is if a producer wanted to pad the line table > for a compilation unit, either for alignment

Re: [Dwarf-Discuss] Location list entries for caller-saved registers at time of call

> > Jakub complains that "the compiler would need to emit a nop after > > every call, which an optimizing compiler is not willing to do." We're > > not talking about *every* call, just the rare case of a no-return > > call. > > They aren't that rare, and even if they would, that is still not

Re: [Dwarf-Discuss] Location list entries for caller-saved registers at time of call

> > This example shows local in %eax, which is a caller-save (i.e., > > scratch) register. GCC is right to show that the value is unknown upon > > return from the call, because set() can clobber that register. > > Sorry, typo -- %eax is a *callee-save* register. Argh! No, I was right the first

Re: [Dwarf-Discuss] Location list entries for caller-saved registers at time of call

> Another perfectly good solution is for the compiler to assure that the return > PC is always in the > right scope to begin with. All it takes is to include a (never executed) NOP > following any non-returning > CALL at the last address of the routine.Such calls are not common, plus many >

Re: [Dwarf-Discuss] dsymutil: "could not find referenced DIE" followed by a segmentation fault and other newbie questions

> 0x0001415e: DW_TAG_imported_declaration [99] > DW_AT_decl_file [DW_FORM_data1] > ("/Applications/Xcode7.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_types/_time_t.h") > DW_AT_decl_line

Re: [Dwarf-Discuss] How to differentiate between multiple inlined segments of same function from line table?

> I am trying to understand how a profiler can get the following > information from a DWARF line table. Let us look at a specific > example: > ... > When foo() is inlined at all the 3 instances, the line number > from the line table will reference the line numbers of the > original foo() function

Re: [Dwarf-Discuss] variable locations - safe use as lvalues

> A debugger cannot currently be told that any particular variable > location expression is safe to use as an lvalue, something roughly > "exclusive, exhaustive, -O0-equivalent". I believe most debuggers > don't even handle the multiple-locations case for writes at all. I > don't know why -

Re: [Dwarf-Discuss] dwarf stack operator for byte swap.

> >> DW_OP_byte_swap > >> > >> The DW_OP_byte_swap operation pops the top stack entry, > >> byte swaps the value > >> and pushes back the swapped value on the dwarf stack. > >> e.g. so 0x12345678 will become 0x78563412, useful to > >> change

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

>> > 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 least be reserved (like DW_SECT value 2 (originally

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

> The pre-v5 dwp format was just a prototype, accessed via > --experimental GCC flags, and I don't think we ever intended to > support mixing pre-v5 dwo files with standard v5 dwo files. Sorry, I was wrong about the --experimental flags. The prototype did get upstreamed under the -gsplit-dwarf

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

Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?

> DW_OP_implicit_value and DW_OP_stack_value produce values (that is > R-values), not locations. I might be able to read > DW_OP_implicit_pointer as providing a location; I'm not sure. No, they don't produce a value. The expression that precedes them produces a value, and these operators produce

Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?

> I think that the description has become a bit less clear with the > addition of the Implicit Location Descriptions in Section 2.6.1.1.4, > which do compute values, rather than locations. Perhaps these should > have been described in Section 2.5 as parts of a DWARF expression, not > as parts of

Re: [Dwarf-Discuss] implicit_value vs stack_value

This is from the minutes of a meeting in 2008... DW_OP_implicit_value is still needed in some circumstances so it will be kept as-is. DW_OP_implicit_value could possibly be used to express something like a floating point number whereas it would be more complex to do the same

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

> 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 > sec_offset for DW_AT_ranges on the skeleton CU)? (& that

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

> 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 function and so the consumer should not try > to

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

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 both LLVM and GCC's emission is incorrect - and >> > that it's not

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

> > 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) DW_AT_rnglists_base. If there isn't, then > > try the

Re: [Dwarf-Discuss] string reduction techniques

>> 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 got mixed feelings about DWARF64 - partly the pieces that

Re: [Dwarf-Discuss] string reduction techniques

>> > I wouldn't be averse to considering what'd take to make DWARF robust >> > enough to always roundtrip simple and linkage names in this way - I don't >> > think it'd take a /lot/ of extra DWARF content. >> >> Fuzzy memory here, but as I recall, GCC didn't generate linkage names >> (or only

Re: [Dwarf-discuss] Proposal: Error: DW_OP_entry_value description and examples

I've added this as issue 230808.1. https://dwarfstd.org/issues/230808.1.html -cary On Tue, Aug 8, 2023 at 9:02 AM Robinson, Paul via Dwarf-discuss wrote: > > # Error: DW_OP_entry_value description and examples > > ## Overview > > DW_OP_entry_value provides a way to compute a value as if the

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

> > Before we can do anything with this, though, we'd need to make sure > > your wife is willing to put her design under a Creative Commons, or > > similar, license. I think Creative Commons is the right choice, as > > that's what we've been using for other content recently. The standard > >

Re: [Dwarf-discuss] ISSUE: update Dwarf_Version_Numbers.md for DWARF5

> It looks like https://wiki.dwarfstd.org/Dwarf_Version_Numbers.md hasn't > been brought up to date with DWARF5 yet. This table can be useful > because the versions of different sections do not necessarily follow the > major DWARF version. It hadn't even been updated to the final DWARF4 spec.

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

Ben, Thanks for forwarding these. Simplification and minimization is the hot new trend in logo design. (Well, maybe not quite so new today.) Everyone's doing it, from Starbucks to Burger King, Shell, MasterCard, and Pringles, to name a few. I like the dwarf in #3, and the font in #1. I think

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

> V2 now with tools: > > http://ssh.bencoyote.net/~ben/DWARF_6_DRAFT_tools.png > > It is kind of a menu. Pick your favorite dwarf body, your favorite > helmet, your favorite tool. Or suggest something different. Since it is > just a draft she just just did it over the DWARF6 mockup - we can >

Re: [Dwarf-discuss] ISSUE: tensor types. V3

Added as Issue 230413.1: https://dwarfstd.org/issues/230413.1.html -cary On Thu, Apr 13, 2023 at 11:57 AM Ben Woodard via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Here is V3 of what was my vector types proposal. > > Changes since V2: > > We discussed this extensively in the

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

> There is no statement if tables must be contiguous or if > there can be padding between the tables. I've added this as Issue 230329.1. Thanks! -cary -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

> Vector registers > > It has been the long standing existing practice to treat hardware > vector registers as arrays of a fundamental base type. To deliniate > these hardware register arrays from arrays in the language source they > have been given the DW_AT_GNU_vector attribute. This proposal

Re: [Dwarf-discuss] Enhancement: Expression Operation Vendor Extensibility Opcode

I've added this as DWARF Issue 230324.1. I'll report back after the committee has reviewed it. Thank you for your contribution! -cary On Fri, Mar 24, 2023 at 1:21 PM Linder, Scott via Dwarf-discuss wrote: > > [AMD Official Use Only - General] > > Background > == > > The vendor

Re: [Dwarf-discuss] Request for adding a Mojo Language Attribute

> https://dwarfstd.org/issues/230502.1.html I've marked this issue as accepted, and have assigned DW_LANG_Mojo = 0x0033, with a default lower bound of 0. For DWARF 6, I've also assigned DW_LNAME_Mojo = 0x001f. -cary -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org

Re: [Dwarf-discuss] Other - Broken link on dwarfstd.org homepage

> > the dwarfstd.org homepage, under "DWARF Introduction", contains a > > broken link labeled "Introduction to the DWARF Debugging Format". > > > > The link points to: > > https://dwarfstd.org/doc/Debugging-using-DWARF-2012.pdf > > and opens a "Not found" error page. > > The original file had

Re: [Dwarf-discuss] Link to current working DWARF6 standard

We agreed in the April 17 meeting to make the working copies of the DWARF spec public. I've added a DWARF 6 section to the home page, with a link to the working draft snapshots, and I've added DWARF 6 to the downloads page. -cary On Mon, Jun 19, 2023 at 2:11 PM Mark Wielaard via Dwarf-discuss

Re: [Dwarf-discuss] Request for adding a Mojo Language Attribute

Thanks for your proposal! I've added this to our list of issues: https://dwarfstd.org/issues/230502.1.html -cary On Tue, May 2, 2023 at 5:46 PM Walter Erquinigo via Dwarf-discuss wrote: > > I'm kindly requesting the addition of a new language name to describe Mojo. > The Mojo language is

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

This is Issue 240118.1. https://dwarfstd.org/issues/240118.1.html -cary On Thu, Jan 18, 2024 at 11:08 AM Robinson, Paul via Dwarf-discuss wrote: > > # Allow padding in all tables > > Enhancement; multiple sections. > > ## Background > > Issue 230329.1 requires all tables to be contiguous.

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

> ### .debug_abbrev > > In Section 7.5.3 "Abbreviations Tables" (p.207), at the end of the section, > add a new non-normative paragraph: > > *This table may be padded by adding an unused abbreviation entry. The minimum > number of bytes in an abbreviation entry is four (abbreviation number,

Re: [Dwarf-discuss] Language code for the Hylo language

> The Hylo compiler (https://hylo-lang.org) is not generating debug info yet, > but it will, and we'd like it if tools like LLDB were ready for us, so I'm > requesting that a new language code be added for Hylo to > https://dwarfstd.org/languages-v6.html Added as issue 240213.1:

Re: [Dwarf-discuss] New Language Name for Move

> We are kindly requesting the addition of a new programming language name to > describe Move. The Move smart contract programming language is described in > https://github.com/move-language/move. Added as issue 240202.1: https://dwarfstd.org/issues/240202.1.html I've assigned new

Re: [Dwarf-discuss] [Enhancement] New language code - Ruby

> I would like to request addition of a new language code for the Ruby[1] > language. > > Based on the latest snapshot[2] (from December 5th, 2023) the required > changes are as follows: > > [Section 3.1.1, p 65, Table 3.1. Language Names] - Add > > DW_LNAME_Ruby Ruby > > [Section 7.12, p 243,

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

Added as new issue 231110.1 . -cary On Fri, Nov 10, 2023 at 1:52 PM Ben Woodard wrote: > DWARF Extension Registry > Background > > The DWARF standard has always had the wisdom to acknowledge the need for > Vendor Extensibility. Section 1.3.13

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

> > > >DW_LANG_HIP/DW_LNAME_HIP was assigned first, but for some reason, the > list was out of order, so when I assigned >DW_LNAME_Assembly, it looked > like 0x001c was the last code assigned. I think it would be safer to > reassign >DW_LNAME_Assembly as 0x0029. > > I think it would be safer to

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

Added as Issue 240424.2 , with Jakub's corrections. -cary On Wed, Apr 24, 2024 at 2:50 PM Jakub Jelinek via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss > wrote: >

Re: [Dwarf-discuss] Proposal: Define a language version scheme for Swift

I've added this as Issue 240422.1 . -cary On Mon, Apr 22, 2024 at 5:01 PM Adrian Prantl via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > # Swift Language version scheme > > ## Background > > The list of languages at

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

> > Actually, it would help my process if you would announce at each meeting > what language names and their corresponding issue numbers were processed in > the prior period. The point is to get that information into the Minutes. No > discussion needed, just an announcement. Actually if that

Re: [Dwarf-discuss] Proposal: Add versioning scheme for Fortran

Added as Issue 240424.1 . -cary On Wed, Apr 24, 2024 at 2:37 PM Adrian Prantl via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > # Add versioning scheme for Fortran > > ## Background > > The list of languages at

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

> > > It appears that DW_LNAME_HIP, proposed in 230120.4, never got > incorporated into the DWARF working document (so there is no duplication). > Perhaps because the Issue status is "Code Assigned" rather than Approved. > That status really only applies to the V5 code assignment actually. >

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

> > It appears that DW_LNAME_HIP, proposed in 230120.4, never got > incorporated into the DWARF working document (so there is no duplication). > Perhaps because the Issue status is "Code Assigned" rather than Approved. > That status really only applies to the V5 code assignment actually. > >

Re: [Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties)

I've posted this as issue 240507.1 . -cary On Wed, May 8, 2024 at 3:47 AM Martin via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Small correction > >property MyProp: integer read public MyFunc write MyMember; > > Should be >

Re: [Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties)

> > It will support the following new attributes > * DW_AT_Default_Property flag >Specify this is a default property > * DW_TAG_Property_Setter > * DW_TAG_Property_Reader > * DW_TAG_Property_Default > * DW_TAG_Property_Stored > > ### `DW_TAG_Property_[Setter|Getter|...]` Should these all be

Re: [Dwarf-discuss] Proposal: Describe prologue and epilogue ranges

On Mon, Mar 18, 2024 at 2:06 PM Robinson, Paul via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > After today's call, hearing some viewpoints and hopefully learning a > few things, I thought I'd take a stab at reframing 240108.1. (Without > once mentioning CFI!) It ended up becoming

[Dwarf-discuss] Proposal: Clarify Description of Line Table Compression

This is a proposal to clarify the description of line table compression, all in non-normative text. Added as Issue 240320.2 . -cary ## Background Technically, the DWARF spec doesn't really describe the compression technique used for line table rows

[Dwarf-discuss] Proposal: Add Local and Indirect Strings to Name Index

Over on the generic-abi mailing list, Fang-Rui Song recently proposed a new compressed relocation format for ELF, motivated in part by the number of relocations for string in the .debug_names tables. Regardless of the resolution of that proposal, some simple changes to the DWARF spec could help

Re: [Dwarf-discuss] Proposal: Add Local and Indirect Strings to Name Index

> > Over on the generic-abi mailing list, Fang-Rui Song recently proposed a > new compressed relocation format for ELF, motivated in part by the number > of relocations for string in the .debug_names tables. Regardless of the > resolution of that proposal, some simple changes to the DWARF spec

Re: [Dwarf-discuss] Location expressions for partially-optimized-out structs

> The text for DW_OP_bit_piece, on the other hand, does explicitly > contemplate this, containing the language: > > If the location description is empty, the offset doesn’t matter and > the DW_OP_bit_piece operation describes a piece consisting of the > given number of bits whose values are