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

The DWARF committee has voted to reject this proposal for DWARF 6. The committee felt that the cost of updating line numbers without the proposed indirection was not clearly shown to be unreasonable. We would be willing to reconsider the proposal at a later date if implementation experience shows

Re: [Dwarf-discuss] Dwarf language code for P4 langauge

Added as Issue 240725.1. I've assigned the following language codes for P4: DW_LANG_P4 = 0x003c (for DWARF 5 and earlier) DW_LNAME_P4 = 0x002b (for DWARF 6) -cary On Mon, Jul 29, 2024 at 7:14 AM Robinson, Paul via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Thanks. CC’ing the l

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

Alexandre, It sounds like you still would like to propose a change to DWARF. Can I ask you to come back with a formal proposal? It's OK if you're not sure of one alternative over another, but I'd like to see something more specific in terms of what changes you'd like to make. -cary On Tue, Jul

Re: [Dwarf-discuss] Add DW_LANG_Odin for the Odin Language

> According to the Odin designer, the versioning scheme MM is correct > for Odin. Updated. Thanks! -cary -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

Added as Issue 240626.1 . -cary On Wed, Jun 26, 2024 at 4:06 PM Matthew Lugg via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > # Add DW_LNS_indirect_line - update `line` to absolute value stored > indirectly > > ## Background > > In many s

Re: [Dwarf-discuss] Add DW_LANG_Odin for the Odin Language

Added as Issue 240627.1 . For DW_LANG_Odin, I've assigned 0x003b (not 0x43). For DWARF v6, I've assigned DW_LNAME_Odin = 0x002a. If you'd like to add a version scheme, let me know. -cary On Thu, Jun 27, 2024 at 8:12 AM Christoffer Lernö via Dwarf-disc

Re: [Dwarf-discuss] Proposal: rnglists_base missing

Added as Issue 240618.2 . -cary On Tue, Jun 18, 2024 at 3:40 PM David Anderson via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > BACKGROUND: > References are to DWARF5 unless otherwise indicated. > > > If a split-full CU uses DW_FORM_rnglis

Re: [Dwarf-discuss] Proposal for DW_AT_rnglists_base table F.1

Added as Issue 240618.1 . -cary On Tue, Jun 18, 2024 at 2:43 PM David Anderson via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > BACKGROUND: > References are to DWARF5 unless otherwise indicated. > > The basic issue is that .debug_rnglists

Re: [Dwarf-discuss] Proposal: Add C++23 DW_AT_language_version code

On Sun, Jun 16, 2024 at 3:44 PM Victor Chernyakin via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > This is a proposal to add a version code for the latest ISO C++ standard, > C++23, > to the informative table at https://dwarfstd.org/languages-v6.html. Its > value should be 202302 [1]

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

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 D

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 inform

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

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 https://dwarfstd.org/language

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 https://dwarfstd.org/la

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. > I've

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

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

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 coul

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

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 an

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 undefin

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: https://dw

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 languag

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

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

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

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 describe

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

I've added this as Issue 231013.1: https://dwarfstd.org/issues/231013.1.html -cary On Fri, Oct 13, 2023 at 3:50 PM David Blaikie wrote: > > (derived from: > https://lists.dwarfstd.org/mailman/private/dwarf-workgroup/2023-October/002444.html > ) > > # Tombstoning TU entries in `.debug_names` >

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 val

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

> 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 https://lists.dwa

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 space

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 desc

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 DW

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

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 sim

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

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

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. I've

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 sim

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 did

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

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 pos

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 synthesi

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 the

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

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 DW_TAG_skeleton_unit (and then some DW_AT_ranges in >> .debug_inf

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 t

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 fla

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 DW_S

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 statemen

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 a

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

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 endian

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 b

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

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 tim

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 enough

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

> Speaking generally, a producer should describe the code generated and > nothing more. It should not attempt to anticipate or compensate for the > behavior of a consumer. That leads to bugs in the consumer causing > bugs in the producer. The reverse is true, naturally, but consumers > often hav

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

> I think clang is correct. > > As I read the loclists, from 0x8 up to but not including 0xf, the > value is in reg0, from 0xf (after the call) up to but not including > 0x16, the value is on the stack. > > I don't see that this describes the value as live (in a register) > after the call, at PC =

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

> >>> For calls, we need to distinguish the locations that are valid in the > >>> caller > >>> on the call instruction before the call instruction has been executed, > >>> then > >>> locations that are valid while inside of the call and finally locations > >>> that > >>> are valid after the call

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. -cary __

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

> In the following example I used GCC 7.3.0, and compiled the below > listed C code using `-O1 -gstrict-dwarf -gdwarf-5'. > > extern int get(); > extern void set(int); > > int main() { > int local = get(); > set(local); > local = 123; > return local; > } > > This produces th

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

> > In fact, the PA-RISC and Itanium calling conventions specifically require > > this. > > Not all ABIs do this. Many allow the end of one function to be > immediately followed by the start of the next function. We're talking about the narrow case of a function that ends with a no-return call.

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

Re: [Dwarf-Discuss] .debug_frame and the base address

> I'm interested in the final state of an executable or shared object > and I don't expect to find any remaining ELF-style (e.g. > R_AMD64_64 and the like) run time (ld.so) relocations in non-loadable > .debug_* sections. No, you're not going to see any dynamic relocations for non-loadable section

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 note, > some consumers wi

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 pu