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

[Cary Coutant via Dwarf-Discuss]

> 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 purposes or to leave
> room for expansion (e.g. to simplify incremental linking).

One technique you haven't mentioned is to stretch out LEB128 numbers
with extra 0x80's. For example, you can represent 0 as a single byte
0x00, or as a string of bytes 0x80 80 80 80 ... 00. It's not advisable
to make the string arbitrarily long, as many LEB128 readers will have
sanity checks in them to stop reading after 5 bytes (for 32-bit
readers) or 10 bytes (for 64-bit readers). But you could certainly use
this technique to pad out the final end sequence opcode to a 4- or
8-byte boundary.

When doing an incremental link, gold will pad the .debug_line section
with a dummy line number program of appropriate length (minimum 29
bytes). Here are the relevant comments:

  // Version of the header.  We write a DWARF-3 header because it's smaller
  // and many tools have not yet been updated to understand the DWARF-4 header.

  // Write header fields: unit_length, version, header_length,
  // minimum_instruction_length, default_is_stmt, line_base, line_range,
  // opcode_base, standard_opcode_lengths[], include_directories, filenames.
  // We set the header_length field to cover the entire hole, so the
  // line number program is empty.

  // Some consumers don't check the header_length field, and simply
  // start reading the line number program immediately following the
  // header.  For those consumers, we fill the remainder of the free
  // space with DW_LNS_set_basic_block opcodes.  These are effectively
  // no-ops: the resulting line table program will not create any rows.

When doing an incremental update, if the replacement .debug_line
contribution is bigger than what it's replacing, I fill the old
contribution with the dummy header, and allocate the space I need from
another padding area. When allocating space out of a padding area, I'm
careful to make sure that the remaining space, if any, is at least 29
bytes, so it can again be filled with a dummy line number program.

I use a similar technique to pad the .debug_info and .debug_types
sections. Those are a bit easier, since we can simply pad the actual
data area with zeroes.

> Another reason is if the linker decides to omit a function (e.g. if
> nothing references it, the code can be dead-stripped) then it could
> overwrite the related sequence(s) in the line-number program, rather
> than remove then and shrink the entire line table.

Another thing you can do is "hide" stuff inside an undocumented
extended opcode. Because extended ops always declare their length, you
can make a single extended op cover whatever hole you have (as long as
it's at least 3 bytes). If you use an extended opcode of, say 0x7f,
which hopefully no one has implemented, any conforming DWARF reader
will simply skip over it without complaint. (I did find one reader at
Google that complained about unknown extended ops, but I was able to
fix that one.) Be wary of playing with the length field for a known
extended op, however, because some readers will simply assume they
know how to parse a known op, and will ignore the explicit length
field (just as they often ignore the standard_opcode_lengths array for
standard opcodes that they know about).

When I was prototyping two-level line tables, I used this trick to
hide the actuals table inside the logicals table, so legacy DWARF
readers would simply see the logicals table as the regular line table.
I even hid the extra prologue header fields inside that block -- the
first new field in the extended header was actually the "magic"
extended op that covered the rest of the header plus the actuals table
itself.

> Arguably you could just increase the length in the header, but then
> a dumper (or other consumer) could become confused by whatever is left
> after the last sequence.  I think the padding needs to make sense to a
> consumer; i.e., syntactically it needs to look like another sequence.
>
> In order to look like a sequence, the padding would have to end with
> an end-sequence extended opcode, which is three bytes. Poking around
> in the spec for something that would effectively behave as a one-byte
> NOP, it looks to me like there are a few standard opcodes that take no
> operands and do not generate rows in the virtual line table:
> DW_LNS_negate_stmt
> DW_LNS_set_basic_block
> DW_LNS_set_prologue_end
> DW_LNS_set_epilogue_begin

You can also use DW_LNS_advance_pc with an arbitrary length LEB128 "0".

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

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 will decide it's corrupted data).

I don't think it's abuse of the format at all, as long as you don't go
over the reasonable maximum length. There's nothing in the spec that
requires an LEB128 to be minimum length, and in fact there's a case in
the generation of Gnu exception handling tables where the assembler
actually *must* generate a non-minimal LEB128. (It needs to generate a
length field that represents the length of a block that must be padded
to a multiple of 4 bytes, but if the required length is, say, 128, the
length field takes 2 bytes, but that decreases the padding by one
byte, so that the length is now 127, which only takes 1 byte, adding
that byte back to the padding. To avoid an infinite loop there, it
generates a two-byte 127 value.)

>> When doing an incremental link, gold will pad the .debug_line section
>> with a dummy line number program of appropriate length (minimum 29
>> bytes). Here are the relevant comments:
>> ...
>>   // We set the header_length field to cover the entire hole, so the
>>   // line number program is empty.
>
> I have a consumer that whines if the header_length doesn't exactly match
> the fields as defined in the appropriate DWARF version.  But maybe I can
> make it tolerate this.
>
>>   // Some consumers don't check the header_length field, and simply
>>   // start reading the line number program immediately following the
>>   // header.  For those consumers, we fill the remainder of the free
>>   // space with DW_LNS_set_basic_block opcodes.  These are effectively
>>   // no-ops: the resulting line table program will not create any rows.
>
> I still say it's syntactically invalid unless it ends with end_sequence.
> But otherwise this is "great minds think alike."

What DWARF says is: "Every line number program sequence must end with
a DW_LNE_end_sequence instruction which creates a row whose address is
that of the byte after the last target machine instruction of the
sequence."

If the line table program contains no sequences (i.e., it's empty),
you don't need an end_sequence instruction.

>> I use a similar technique to pad the .debug_info and .debug_types
>> sections. Those are a bit easier, since we can simply pad the actual
>> data area with zeroes.
>
> Again I think I have a whiny consumer but it can probably be fixed.

We need to crack down on whiny consumers. They defeat the
extensibility that we designed into DWARF.

>> Another thing you can do is "hide" stuff inside an undocumented
>> extended opcode. Because extended ops always declare their length, you
>> can make a single extended op cover whatever hole you have (as long as
>> it's at least 3 bytes). If you use an extended opcode of, say 0x7f,
>> which hopefully no one has implemented, any conforming DWARF reader
>> will simply skip over it without complaint.
>
> Ooh I like that.  Should we officially reserve an opcode for this?

A DW_LNE_comment opcode? You could propose it for DWARF 6.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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
sections. Linkers typically do not generate dynamic relocations for
these sections even in the presence of an R_*_64 relocation which
would result in either an R_*_64 or an R_*_RELATIVE dynamic relocation
for a loadable section. Instead, the consumer (e.g., debugger) is
expected to have enough context to know where it might find addresses
that will need runtime relocation.

> My question instead concerns things like initial_location in an FDE,
> which is interpreted relative to the base address of the enclosing
> load object.  I can see that DW_CFA_set_loc's operand would also
> need to be interpreted as relative to the same base address.

Yes, both the initial_location and the operand of DW_CFA_set_loc would
be link-time relocated to an address in the image, but would need
run-time relocation by the consumer if the load address does not match
the link-time address.

Things get more complicated with Gnu .eh_frame sections -- these carry
an augmentation string that says such addresses are actually
pc-relative offsets. If you look at the relocations in the object
file, you can see R_*_PC32 relocations (or equivalent). These are used
because the .eh_frame sections are part of the text segment and
absolute relocations would have resulted in dynamic relocations in
text.

> However,
> I'm trying to establish if there's anything else within .debug_frame that
> would be expressed relative to the same base address.  For example,
> DW_CFA_expression assumes that the CFA is already on the stack and it
> would be perverse to expect the result to be anything other than an
> absolute address.

Correct. Any addresses you get from registers at runtime will not need
further relocation.

> But is the same true of DW_CFA_def_cfa_expressions?
> What about instructions within the expressions themselves...
>
> The DW_OP_addr case is confusing.  As it's an object address its
> operand is highly likely to require an ELF-style (ld-style) relocation
> to produce an appropriate address in the linked object.  However, I
> can see that in a shared object it would be plausible that the final,
> ELF-style relocated argument should additionally need to be interpreted
> as relative to the load object's base address.  I assumed Greg was
> asserting the latter with:
>
> > On 24 Sep 2018, at 15:33, Greg Clayton  wrote:
> >
> > Any DWARF expression can contain a DW_OP_addr, which has an address 
> > argument, and would need to be relocated.

Yes. DW_OP_addr is used to provide a symbolic address, which will need
relocation at both link time and load time.

> and, not remembering any mention to the contrary in DWARF 2/3/4
> wondered if this was really the case --- it would certainly have
> helped answer my actual concern about .debug_frame.  However, the
> follow-up references to DWARF 5 7.3.1 and 2.5.1.1 are discussing
> ELF-style relocations, and are, unfortunately, red herrings.

That's not a red herring. Relocations are relocations, whether they're
"ELF-style" or implicit by context, and both linker (static) and
dynamic relocations are "ELF style". Debug sections don't have dynamic
relocations simply because they're unloadable and we can leave it up
to the consumer to figure out where all the relocatable addresses are.
(Otherwise, debug info would be even more expensive than it already
is!)

The new material in Section 7.3.1 about what needs relocation is
clarifying material that was just as true for DWARF 2, 3, and 4. That
was an attempt to pre-emptively answer your questions above.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 
> environments align
> the beginning of (any subsequent) functions anyway so padding bytes are 
> likely to be available. As a
> result, such "extra" bytes are not going to be a space issue.

In fact, the PA-RISC and Itanium calling conventions specifically require this.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> > 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. In all other situations, of course it's fine to have
one function immediately follow the previous.

This also applies to no-return calls in the interior of a function,
where the next instruction might be part of a code region with
different unwind descriptors.

> Subtracting one from the return address is a trivial way to insure
> that the address is within the calling function and not in the
> next function.  And it works on all architectures.

It's not exactly trivial: it's not always correct to do this (e.g.,
when unwinding from a signal handler), and the unwinder needs to know
how to recognize those kinds of frames. For PA-RISC and Itanium, we
elected to make the rule simple: the pc value, whether it derives from
a return pointer or a sigcontext, will always get you the correct
unwind information.

But we're getting sidetracked from the OP's question: Does GCC in fact
subtract one from the upper bound of a location list entry for a
variable contained in a caller-saved register? I can think of no
reason why it should do this. If the compiled code does something like
this:

A: promote variable X into caller-save register R
   ...
   call f
B: ...
   spill register R back to X
C: ...

The location list entry for x should show it live in register R in the
range [A..C). The call should not interrupt the range.

It sounds like David has an example where the range list entry shows x
in register R in the range [A..B-1), then presumably again for [B..C),
leaving [B-1..B) uncovered. That would be a bug, in my opinion.

David, can you show us an example?

-cary

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 the following location list for `local':
>
> 000c 000e 0014 (DW_OP_reg0 (rax))
> 0011 0015 001f (DW_OP_const1u: 123;
> DW_OP_stack_value)
>
>9:   e8 00 00 00 00  callq  e 
>e:   89 c7   mov%eax,%edi
>   10:   e8 00 00 00 00  callq  15 
>   15:   b8 7b 00 00 00  mov$0x7b,%eax
>
> As seen, there is a one-byte gap at the end of the call instruction to
> set().

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.

Try changing your code so that you use the value of local after the
call to set() -- say, make it "local += 123" -- and see the
difference. My copy of GCC moves local to %ebx, which is a caller-save
register, and the location list shows it live in that register all the
way through the call and return.

> If we instead use Clang, there is no gap in the location list for the
> same code:
>
> [0x0008, 0x000f): DW_OP_reg0 RAX
> [0x000f, 0x0016): DW_OP_consts +123,
>   DW_OP_stack_value)
>
>3:   e8 00 00 00 00  callq  8 
>8:   89 c7   mov%eax,%edi
>a:   e8 00 00 00 00  callq  f 
>f:   b8 7b 00 00 00  mov$0x7b,%eax
>
> When debugging the Clang-built binary in GDB, when unwinding from set()
> to main(), `local' will be evaluated using the value RAX has in set(),
> rather then being printed as "".

I think clang is wrong here. Because the call can clobber the
register, the compiler should not claim that the value is live upon
return.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> >>> 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 has returned.
> >>
> >> But the call instruction is atomic.  There are not distinct PC locations
> >> within an individual call instruction.
> >
> > The instruction itself is, but the invocation of the called procedure is
> > not.
>
> So?  The return address doesn't slowly creep through the call
> instruction as the called procedure executes.

Jakub is correct. It's not that the return address creeps slowly
through the call instruction -- it's that there are three distinct
phases in the call:

1: before the call (pc is at the call instruction)
2: during the call (pc is in the called function, and rp points to the
instruction after the call)
3: after the call (pc is at the instruction after the call)

Before the call (1), the value is still live in %eax, so the range
should include the address of the call instruction.

During the call (2), the value is unknown, because %eax is
callee-save. As postulated, GCC is aware that unwinders will subtract
1 from the rp, so it knows that it can exclude this phase from the
range list entry by subtracting one from the address of the next
instruction. (It could just as easily used the address of the call
instruction + 1.)

After the call (3), the value is still unknown. Setting the end of the
range to the address of the instruction following the call would have
covered this, but not the time during the call.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 = 0xf.

But *during* the call, when the unwinder will use a PC value of 0xe to
query the range list, it will think the value is still live in %eax,
which is not true. If the unwinder did not subtract 1 from the PC
value, it would get the right answer, but since it does subtract 1,
GCC needs to adjust the end of the range list entry.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 have to adapt to odd (or buggy) producers.

And that's another reason why on PA-RISC and Itanium we have the rule
that the unwind info for the PC of the instruction following the call
must be accurate. With that rule, we do not have to anticipate or
compensate for the consumer. One hack always begets another hack. (Of
course, if some debuggers were to subtract 1 despite that rule, we
would have to either compensate or declare them buggy.)

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.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> > 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.
> For proper debug info one needs to differentiate between the context inside
> of the call and the context right after the call, while in the %eax case
> that has been discussed it makes no difference, in others it does.
>
> Consider:
> void bar (void);
> void baz (int);
> int
> foo (void)
> {
>   int a = 6;
>   bar ();
>   {
> long a = 5;
> baz (10);
>   }
>   return 10;
> }
> If you don't subtract one during unwinding and during the bar call look at
> foo's frame, then it would appear as if you are already at the baz call with
> the inner a variable in scope, but that shouldn't be in scope yet, and if
> user asks for value of a, he should see that 6 and its type should be int,
> not long.

Yes, you're right -- that's a good point. That suggests that perhaps
we should do something more explicit to distinguish between "during a
call" and "after a call". What happens on architectures where the call
instruction is just one addressable unit long? For example, a
word-addressed architecture, or Itanium where some toolchains encode
the slot number as (0, 1, 2) in the low-order bits of the PC?

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> > 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 time. %eax is a caller-save (scratch) register.

Here was the typo:

> Try changing your code so that you use the value of local after the
> call to set() -- say, make it "local += 123" -- and see the
> difference. My copy of GCC moves local to %ebx, which is a caller-save
> register, and the location list shows it live in that register all the
> way through the call and return.

%ebx is a *callee-save* (preserved) register.

I always have to think twice and I still get callee-save and
caller-save backwards! That's why I prefer the terms "scratch" and
"preserved".

Sorry for the confusion. David correctly said it was a caller-save
register in his original mail, and if I hadn't thought "callee-save"
instead, I'd have been able to answer his question straight away.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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_data2] (20047)
> DW_AT_import [DW_FORM_ref4] (cu + 0x4c4f5254 => 
> {0x4c4f5254})
> 
>
> How do I go about understanding the error, what caused it and how to solve it?
> BTW, the lib size being built is around 350MB. Could there be a size issue 
> causing this seg fault?

The offset it gives, 0x4c4f5254, is much too large for a file in the
350MB range, so this is clearly bogus. The value is ASCII for "LORT"
-- it looks like an ASCII string has made its way into your DWARF info
somehow.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 body, i.e. something like lines 7-11, at
> all the 3 inlined segments.
>
> When a profiler looks at this, how can the profiler know which
> inlined instance it is looking at?

With current DWARF, you need to look at the debug info to get inline
information. In the debug info, first look for a declaration of your
inline function that looks something like this DIE:

 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e>   DW_AT_external: 1
<2e>   DW_AT_name: foo
<32>   DW_AT_decl_file   : 1
<33>   DW_AT_decl_line   : 1
<34>   DW_AT_prototyped  : 1
<34>   DW_AT_type: <0x50>
<38>   DW_AT_inline  : 3 (declared as inline and inlined)

The distinguishing features here are the DW_AT_inline attribute and
the lack of a DW_AT_low_pc/high_pc. This is the abstract definition of
your inline function.

Next, if an out-of-line copy of the function was generated, you'll
find a concrete instance of it that may look something like this DIE:

 <1><57>: Abbrev Number: 6 (DW_TAG_subprogram)
<58>   DW_AT_abstract_origin: <0x2d>
<5c>   DW_AT_low_pc  : 0x0
<64>   DW_AT_high_pc : 0x17
<6c>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)

Here, the DW_AT_abstract_origin tells you that it's a concrete
instance of the abstract definition declared above, and gives you the
PC range for the out-of-line code.

Now, for each location where your function has been inlined, you'll
find a DW_TAG_inlined_subroutine DIE nested inside the
DW_TAG_subprogram DIE where it was called.

 <1><85>: Abbrev Number: 9 (DW_TAG_subprogram)
<86>   DW_AT_external: 1
<86>   DW_AT_name: bar
<8a>   DW_AT_decl_file   : 1
<8b>   DW_AT_decl_line   : 10
<8c>   DW_AT_prototyped  : 1
<8c>   DW_AT_type: <0x50>
<90>   DW_AT_low_pc  : 0x17
<98>   DW_AT_high_pc : 0x55
   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
 ...
 <2>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
   DW_AT_abstract_origin: <0x2d>
   DW_AT_low_pc  : 0x1f
   DW_AT_high_pc : 0xe
   DW_AT_call_file   : 1
   DW_AT_call_line   : 11
   DW_AT_sibling : <0xf3>
 ...
 <2>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
   DW_AT_abstract_origin: <0x2d>
   DW_AT_low_pc  : 0x39
<100>   DW_AT_high_pc : 0xe
<108>   DW_AT_call_file   : 1
<109>   DW_AT_call_line   : 13
 ...
 <2><133>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
<134>   DW_AT_abstract_origin: <0x2d>
<138>   DW_AT_low_pc  : 0x53
<140>   DW_AT_high_pc : 0xe
<148>   DW_AT_call_file   : 1
<149>   DW_AT_call_line   : 15

The low_pc and high_pc attributes in each inlined_subroutine DIE will
identify, for a given PC, which inlined instance you're looking at,
and the call_file and call_line attributes will give you the source
file information for the caller. If there are nested inlines, you'll
find nested inlined_subroutine DIEs, so you can follow the call stack
all the way up to the outermost non-inlined function.

> It appeared to me initially the line table discriminator field
> (http://wiki.dwarfstd.org/index.php?title=Path_Discriminators)
> could be used for this. But after further study, I think I need
> something more general.

No, discriminators are for something else entirely.

> It appears I need something like the "context" column at
> http://wiki.dwarfstd.org/index.php?title=TwoLevelLineTables.
> However this does not appear to be in any DWARF spec.

Yes, this proposal would do what you're looking for. It modifies the
line table so that inline information can be represented entirely in
the line table without having to process the DIE structures. See also
DWARF issue #140906.1 [1].

The proposal was deferred to the next revision of DWARF (it was
proposed before DWARF 5 was finalized, but too late to make it into
that revision). There's a prototype implementation on the GCC
google/gcc-4_9 branch and the binutils
users/ccoutant/two-level-line-tables branch. Although that prototype
doesn't quite match the proposal as written, it was close enough to
demonstrate the effectiveness of the idea.

-cary


[1] http://dwarfstd.org/ShowIssue.php?issue=140906.1
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> >>  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 endianity of raw
> >> data.

While I can see the potential usefulness of a byte-swap operator, it's
not clear to me that it's the right approach for Chirag's case. In his
example, the __gbloffset__ variable has a DW_AT_type which is
explicitly given a DW_AT_endianity attribute. A DWARF consumer would
be expected to pay attention to the byte order when presenting the
value of that variable, but the DW_OP_call4 pushes just the address of
the variable as a value of "generic" type, and DW_OP_deref will
dereference it without knowing its type.

What we're missing is an operator to attach a type to the current
value on top of the stack; if we had that, we could do (DW_OP_call4,
DW_OP_attach_type, DW_OP_deref) and expect the DWARF consumer to honor
the byte order and do a byte swap implicitly when executing the
DW_OP_deref.

Or, we could specify that DW_OP_call* should not only push the result
of evaluating the DW_AT_location of the target DIE, but also attach
the DW_AT_type of the target DIE to that value.

Or, we could add DW_OP_call*_type operators, and leave the original
DW_OP_call* operators to deal with values of generic type only.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 - assume complications are rare?  or we have kind of
> papered over the problem?
>
> As a DWARF standard level matter, descriptive rather than prescriptive
> as it is, what might be the minimum extension required to communicate
> lvalue-safety to a debugger?  A DW_OP_lvalue_safe assertive wrapper
> around a real expression?

In DWARF 5, we added the concepts of bounded and default location
descriptions. I think it would generally be safe to modify a value
under the following conditions:

(a) The variable's location is covered by a single location
description, or by a location list with a default location description
but where no bounded location description matches the current pc.

(b) Such location description is a simple memory or register location.

(c) You're stopped at a suggested breakpoint location.

I'm sure there are circumstances where you could still get into
trouble (e.g., your third example), but I think it would be unusual,
and there we'd probably be talking about a quality of implementation
issue. The courteous thing for a compiler to do would be to at least
try to make this ok at suggested breakpoint locations, though I
wouldn't expect a compiler at -O2 to deliberately avoid an
optimization solely for the sake of being able to modify a variable
while stopped at a breakpoint.

In your third example, once the compiler has loaded a copy of the
variable into a register to use in a computation, it could (should?)
create a bounded location description, thus marking it unsafe under
the rules above. So, rather than mark lvalue-safe regions, a compiler
could instead use a bounded location descriptions to mark a region
unsafe that wouldn't already be deemed unsafe.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 Location Description.

Strongly disagree. The whole point of an implicit location description
is to give a (pseudo/virtual) location to a value that has no
location. A DWARF *expression* has no use for these operators.

> The description (and implementation) of DWARF expressions and locations
> are somewhat muddled together.  This can be seen in the first sentence
> of Section 2.5:
> DWARF expressions describe how to compute a value or specify a
> location.
> A clearer definition would specify that the DWARF expression only
> computes a value, and leaving what that value means (e.g.,
> register/memory contents, arbitrary computation, memory address) to the
> context in which the expression is used.  A more precise definition of a
> location, especially a composite location, would help.
>
> Part of this is historical, with the expression evaluation initially
> used to compute a memory address and then extended to accommodate
> composite locations and further extended to compute arbitrary values.
> These extensions were in divergent directions, affecting both location
> composition and value computation.  It would have been better if the two
> concepts were clearly distinguished.

Other than that first sentence of 2.5, I think they are pretty clearly
distinguished. Location descriptions, covered by Section 2.6, are
built on top of DWARF expressions, and provide additional operators
for specifying locations other than simple memory locations.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 a location description
for that value.

> As I said, values and locations are muddled.  If you think that a
> variable which has been eliminated has a location which is described by
> a DW_OP_implicit_value, then we aren't working with the same definition
> of "location".

Evidently not. For values that don't have a location, we have these
operators that provide a location description anyway. Even though
they're not real locations in the sense of existing in memory or a
register, they are locations in the sense that they are described by a
location description.

Perhaps it would help to think of "locations" as what you think of as
locations, and "location descriptions" as something a bit more
general. A location description can describe a real location, or it
can describe something more ethereal.

> This doesn't work with any of the Implicit Location Descriptions,
> because there isn't any "there" there.  They don't result in locations;
> they give the values which would be found if the variable did exist.  So
> they implicitly perform the dereference operation.

Quite the opposite; they perform the inverse of a dereference
operation. They provide something at the level of a location
description that can be dereferenced but has no other purpose.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> Not to derail this thread, but another thing that might be worth checking is: 
> should debug_aranges include non-code addresses. GCC's don't, Clang's do. 
> Sounds like Clang's correct, but GCC is sort of the defacto standard DWARF 
> producer, so might be worth getting an authoritative statement/clarified 
> wording here. (especially since it's intended for lookup, so it's important 
> what is/isn't included, much like debug_names - not so open to leaving it up 
> to "quality of implementation")

I think it comes down to what end-user scenarios you want to support
that would require a fast lookup table for data addresses. The
.debug_aranges section supports scenarios like "the program is stopped
at (or a backtrace contains) this random PC; what can you tell me
about that?"

I don't know if you need to support any such scenarios involving data
addresses. Given that GCC/GDB haven't needed data addresses in the
table, it seems like so far either (a) they have no need to support
such scenarios, or (b) they've found a way around the lack of
fast-lookup info (perhaps by guessing that any data address is likely
to be associated with the current compilation unit).

If you can't find any real need for it, I'd suggest following GCC's
lead and forget about them, obviating the need for using the segment
selector.

If you do still find a need for fast lookup of data addresses, a
segment selector seems like a waste of space, though I don't really
have a problem with the idea of using it there and nowhere else. I'd
be tempted to use a completely separate table, though -- say
.debug_dranges -- as an extension.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

>> > 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_SECT_TYPES) 
>> > was in DWARFv5) in DWARFv6. & maybe open up an extension space in the 
>> > future.
>>
>> That sounds good to me. When I saw that number 2 (debug_types in the
>> fission extension) was reserved, I originally assumed this was what
>> had already happened.

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. I'd
recommend your original option #1 (invalid/unsupported). Thus, you
shouldn't need DW_SECT_LOC or DW_SECT_MACINFO.

The .debug_types sections were moved back into .debug_info sections at
the very last minute, so we just removed DW_SECT_TYPES without
renumbering the later values. As best I recall, that was just a nod
towards some compatibility with the prototype format, but it wasn't
intended to provide for complete compatibility.

I don't believe we ever supported .debug_macinfo in the prototype, so
I wasn't concerned with the renumbering around DW_SECT_MACRO and
DW_SECT_MACINFO.

I agree that we should have reserved an extension range for DW_SECT
values. It's probably safe to pick some arbitrarily large values if
you need to extend this.

For DWARF-64 support, I truly hoped that we wouldn't ever need it, but
if it was ever necessary, the mechanism I had in mind was to simply
replace .debug_cu_index sections with .debug_cu_index_64 sections (and
likewise for .debug_tu_index). Maybe DWARF v6 will address this. Keep
in mind that the .dwp can be an ELFCLASS64 object file, and its total
size can grow larger than 4GB, even if .debug_cu_index can't support
any section offsets larger than 4GB.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

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

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] implicit_value vs stack_value

[Cary Coutant via Dwarf-Discuss]

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 thing with DW_OP_value.

(DW_OP_value was later renamed DW_OP_stack_value.)

-cary




On Mon, Jan 4, 2021 at 11:30 AM Paul Robinson via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> Happy New Year, everybody!
>
> A colleague just had a question for me about DW_OP_implicit_value
> which led me to wonder why we have both that and DW_OP_stack_value.
> Looking at http://dwarfstd.org/ShowIssue.php?issue=071227.1 which
> introduced the latter, it says in part:
>
>   (This operator is similar to DW_OP_implicit_value, issue "070426.1".  The
>   latter only permits the description of values known to be literals at
>   compile-time; this proposal permits the description of values which
>   have known expressions at compile-time.  It is more general; since
>   a sequence of DW_OP_constxx, DW_OP_value can replace every instance
>   of DW_OP_implicit_value, this proposal also includes the removal of
>   DW_OP_implicit value from the standard.)
>
> ...although I don't think "the removal of DW_OP_implicit_value" actually
> happened.
>
> I have come up with only two advantages that DW_OP_implicit_value would
> have, compared to DW_OP_stack_value:
> 1) it can express a value larger than one expression-stack element in
>a single operation;
> 2) it's faintly possible that it's simpler for a producer to produce.
>
> But, DW_OP_stack_value would frequently result in a more compact
> representation, for example:
>   DW_OP_implicit_value 4 0 0 0 0 => 6 bytes
>   DW_OP_lit0 DW_stack_value => 2 bytes
>
> I don't see much value 😉 in actually deprecating or removing
> DW_OP_implicit_value, now that it's out in the world; is it worth
> adding a non-normative note that DW_OP_stack_value is actually more
> general?
>
> Thanks,
> --paulr
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

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_info.dwo that use DW_FORM_rnglistx, but no .debug_rnglists.dwo
>> section).

The original split DWARF proposal, and the prototype implementation
based on DWARF-4 in GCC did not use .debug_rnglists.dwo (this was
before .debug_ranges was converted to .debug_rnglists by issue
160123.1), so we used DW_AT_ranges_base in the skeleton CU so that dwo
files could use DW_AT_ranges with a non-relocatable offset relative to
that base.

With issues 160123.1 (Unify Location Lists and Range Lists) and
160714.1 (Location List and Range List Sections
Improvement/Enhancement), we replaced .debug_ranges with
.debug_rnglists, and made it possible to place range lists into
.debug_rnglists.dwo when using split DWARF.

DW_AT_rnglists_base is useful to reduce the number of relocations in a
non-split-DWARF object file. It's not necessary when placing range
lists into the dwo file, but if it were to be used there, it would not
make sense to put it in the skeleton CU. It's pointless in a split
DWARF situation, since no relocations are necessary for
DW_FORM_rnglistx.

It sounds like the DWARF-5 implementation of split DWARF in GCC still
has some residuals from the prototype based on DWARF-4. That's likely
due to my retirement and the move of the rest of the Google compiler
team over to LLVM.

> I think the spec is ambiguous here:
>
> 3.1.3 "The following attributes are not part of a split full compilation unit 
> entry but instead are 18 inherited (if present) from the corresponding 
> skeleton compilation unit: DW_AT_low_pc, 19 DW_AT_high_pc, DW_AT_ranges, 
> DW_AT_stmt_list, DW_AT_comp_dir, 20 DW_AT_str_offsets_base, DW_AT_addr_base 
> and DW_AT_rnglists_base."
>
> So, on the one hand, if rnglists_base is inherited that implies that 
> rnglists_base on a skeleton CU means rnglists.dwo is not used. (so the only 
> way to use rnglists.dwo is to not have rnglists_base on the skeleton CU and 
> you don't have it on the split full CU and /that's/ how rnglistx in split 
> full unit refer to rnglists.dwo instead of debug_rnglists in the linked 
> executable)

Yes, it would be possible to keep range lists in .debug_rnglists (and
in the .o) under split DWARF, and then DW_AT_rnglists_base in the
skeleton CU would make sense. But that's not the intent.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 there's no way to 
> refer to range lists in the .o (debug_rnglists) from the .dwo - all ranges in 
> the split full unit must be in debug_rnglists.dwo?)

If you've moved range lists over to the dwo, having DW_AT_ranges in
the skeleton CU would be pointless — the consumer would still have to
go find the dwo to get the ranges.

For the case you suggested where it would be useful to keep the range
list for the CU in the .o file, I think .debug_aranges is what you're
looking for.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> 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 synthesize calls to it. Providing much more functionality than that I 
> think will amount to encoding the ad-hoc ABIs that compilers create in these 
> situations (possible, but a fairly non-trivial proposal/enhancement to DWARF)

I believe that's what DW_AT_calling_convention and DW_CC_nocall are
for (Section 3.3.1.1).

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

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 possible to use rnglistx in the skeleton CU (instead you 
>> > must use sec_offset for DW_AT_ranges on the skeleton CU)? (& that there's 
>> > no way to refer to range lists in the .o (debug_rnglists) from the .dwo - 
>> > all ranges in the split full unit must be in debug_rnglists.dwo?)
>>
>> If you've moved range lists over to the dwo, having DW_AT_ranges in
>> the skeleton CU would be pointless — the consumer would still have to
>> go find the dwo to get the ranges.
>>
>> For the case you suggested where it would be useful to keep the range
>> list for the CU in the .o file, I think .debug_aranges is what you're
>> looking for.
>
>
> aranges has been off by default in LLVM for a while - it adds a lot of 
> overhead (doesn't have all the nice rnglist encodings for instance - nor can 
> it use debug_addr, and if it did it'd still be duplicate with the CU ranges 
> wherever they were).
>
> DWARFv5 says:
>
> "A skeleton compilation unit may have additional attributes, which are the 
> same as for conventional compilation unit entries except as noted, from among 
> the following:
>   2. Either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a 
> DW_AT_ranges attribute."
>
> and
>
> "The following attributes are not part of a split full compilation unit entry 
> but instead are inherited (if present) from the corresponding skeleton 
> compilation unit: DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, ..."
>
> Even before the rnglist move, this still disallowed using DW_AT_low/high_pc 
> with addrx encodings from the split full unit, instead requiring them to be 
> in the skeleton unit. I think this is the right call (& guess it was 
> motivated by this use case) to make for cheap unit lookup.

Hmm. I'm thinking that wording is from before the rnglist move, and
did not get updated properly. Or maybe it was intentional, but not
thought all the way through. Forcing DW_AT_ranges to be in the
skeleton CU when the actual range lists are in the dwo is silly.
DW_AT_low_pc/_high_pc in the skeleton makes sense, though.

But you've got me thinking Perhaps we should have *both*
.debug_rnglists *and* .debug_rnglists.dwo. The former could contain
only the range list needed for the DW_AT_ranges attribute in the
skeleton CU, while the latter would contain the range lists for any
DW_AT_ranges attributes in the dwo sections.

If you (LLVM) are already choosing not to use .debug_aranges for quick
address lookup, does that suggest that per-CU ranges are sufficient?
Can we get rid of .debug_aranges?

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-Discuss]

> > 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 file's .debug_rnglists section, using
> > DW_AT_rnglists_base.  If there isn't, then something is malformed.

Looks reasonable to me. I think we need a new issue to clarify this in DWARF 6.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] string reduction techniques

[Cary Coutant via Dwarf-Discuss]

>> 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 we're 
> seeing with the need for some solutions for mixed DWARF32/64, etc, makes it 
> feel like maybe it's not got a bit of "settling in" to do. And I'm still 
> rather hopeful we might be able to reduce the overheads enough to avoid 
> widespread use of DWARF64 - but it's not a sure thing by any means.

Agreed. I'd like to explore as many avenues as we can to eliminate the
need for DWARF64.


>> Honestly, I've never been sure why gcc generates DW_AT_linkage_name.  Our
>> debugger almost never uses it.  (There is one use to detect "GNU indirect"
>> functions.)  I wonder if it would be possible to avoid them if you provided
>> enough info about the template parameters, if the debugger had its own name
>> mangler.  I had to write one for our debugger a couple years ago, and it
>> definitely was a persnickety beast.  But doable with enough information.  
>> Mind
>> you, I'm not sure there is enough information to do it perfectly with the 
>> state
>> of DWARF & gcc right now.
>
> Yeah, that was/is certainly my first pass - the way I've done the DW_AT_name 
> one is to have a feature in clang that produces the short name "t1" but then 
> also embeds the template argument list in the name (like this: 
> "_STNt1|") - then llvm-dwarfdump will detect this prefix, split up the 
> name, rebuild the original name as it would if it'd been given only the 
> simple name ("t1") and compare it to the one from clang. Then I can run this 
> over large programs and check everything round-trips correctly & in clang, 
> classify any names we can't roundtrip so they get emitted in full rather than 
> shortened.
> We could do something similar with linkage names - since to know there's some 
> prior art in your work there.
>
> 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 in some very specific cases) until the LTO folks
convinced us they needed it in order to relate profile data back to
the source. Perhaps if we came up with a better way of doing that, we
could eliminate the linkage names.

-cary

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] string reduction techniques

[Cary Coutant via Dwarf-Discuss]

>> > 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 in some very specific cases) until the LTO folks
>> convinced us they needed it in order to relate profile data back to
>> the source. Perhaps if we came up with a better way of doing that, we
>> could eliminate the linkage names.
>
> Yeah, fair - it's certainly what we use it for still, authoritative names for 
> functions - including some amount of semantic information (so, for instance, 
> I believe a hash is inadequate) which allows limited rewriting (when we 
> changed standard libraries we were able to remap previous profile samples to 
> line up with the new names (different inline namespaces, implementation 
> names, etc) so as not to take a temporary perf hit as profiles were 
> regenerated, etc).

Just dug up this little bit I wrote up for a "DWARF Best Practices"
wiki article:

The producer may also generate a DW_AT_linkage_name attribute for
program objects, but the presence of this attribute should never be
required to distinguish one program object from another. The DIE
hierarchy is able to provide qualifiers for the name, and the
DW_AT_name attribute itself provides template parameters. In the case
of overloaded functions, the DW_TAG_formal_parameter DIEs belonging to
the function DIE can provide the necessary information to distinguish
one overload from another. In many cases, however, it is expensive for
a consumer to parse the hierarchy, and the presence of the mangled
name may be beneficial to performance. In other cases, the producer
may choose to generate a limited subset of debug information, and the
mangled name may substitute for the missing information.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Cary Coutant via Dwarf-discuss]

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 simplifying the
logo is a good thing, and I like the simplicity of these examples, but
I think the feet (as in #1 and #3) are important. I agree with David
and Ron that a tool would be better than a weapon.

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 is Gnu FDL, but the website itself (at least more recent stuff)
is CC-BY.

(Personally, I always thought our current mascot looks more like a
Tasmanian devil wearing a Viking hat.)

-cary

On Wed, Mar 22, 2023 at 1:01 PM Ron Brender via Dwarf-discuss
 wrote:
>
> FWIW, the "master" in the DWARF .git distro is an .eps file not .png--not 
> that that really matters. I don't know
> where it came from other than Michael gave it to me to use. The .eps does 
> contain some Copyright lines, namely
> % Copyright (c)1992-98 Corel Corporation
> % All rights reserved. v8.0 r0.15
> I suspect it came out of some WordPerfect sample graphics selection which he 
> tweaked for DWARF use--my speculation.
>
> None of which really addresses the question of replacing it. I am OK with 
> considering a replacement but not eager to
> spend much time on it.
>
> I don't much care for any of the quickie examples offered by Ben. The 
> stylized DWARF is no fun and certainly doesn't
> look like a DWARF. The others are too much text and not enough little guy. 
> And I agree with David that the Dwarf
> should be holding a tool (the suggestion of a blacksmith hammer is cool) and 
> not a weapon.
>
> Such are my thoughts at the moment...
>
> Ron
>
>
> On Wed, Mar 22, 2023 at 1:52 PM David Blaikie via Dwarf-discuss 
>  wrote:
>>
>> 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 simple/clear outline, square on one end, tapered on the other)
>>
>> As for version-specific logos, as fun as it might be, practically I'd
>> be happy to settle on a consistent way to render versions - putting a
>> number in the upper right corner, perhaps (have the dwarf hold the
>> tool in their right hand, so would appear on the left of the image -
>> or swap version/tool around as folks see fit).
>>
>> In general my personal font choice is more around example (4), but the
>> thick/sturdy-ness of (2) is probably more in keeping with the theme.
>>
>> On Tue, Mar 21, 2023 at 2:44 PM Ben Woodard via Dwarf-discuss
>>  wrote:
>> >
>> > It has been kind of tense around here for a while; let's have some fun.
>> >
>> > The DWARF logo is quite old. There are many problems with it as a logo.
>> >
>> > It is a png and though there appears to be several versions of it at 
>> > different sizes it is a raster and so it doesn't scale well
>> > The image itself looks scanned and then colored. This leads to some built 
>> > in aliasing on a pixel level which show up badly when printed.
>> > The color choices are not really ideal for printing and if we were going 
>> > to use it on anything other than on a web page like a shirt or a sticker 
>> > there would be problems.
>> > If you look at it up close, it is not really clear.
>> >
>> > I could probably go on and if people would like additional justification I 
>> > will but with the new administration and the push to DWARF6, I think that 
>> > we should consider a new logo. My wife happens to be a graphic designer 
>> > https://cyansamone.com/ and one of the things that she does is logo 
>> > design. When she came into my office and the DWARF5 standard was up on my 
>> > screen and she cringed for about the 50'th time at the logo, I asked her 
>> > to put together some ideas. In a few minutes, she came up with some 
>> > options. http://www.bencoyote.net/~ben/DWARF_logo_1.png
>> >
>> > The fonts (all free as in beer) and images are mix and match and any other 
>> > ideas are more than welcome. They are vector art and so they can be 
>> > scaled. This was just a quick mockup.
>> >
>> > I also thought it might be fun to have a DWARF6 specific logo that we 
>> > could put on tools as they become capable of handling the new version of 
>> > the standard. Another idea that I had but she hasn't drawn yet is the 6 
>> > dwarves chasing a bug. She said that drawing that would take more than the 
>> > 5 minutes she had at the moment because she would have to figure out what 
>> > the dwarves look like i

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

[Cary Coutant via Dwarf-discuss]

> 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 updated it
with the latest from the DWARF5 spec. I didn't bother with the .dwo
sections, since they're basically the same (in v5) as their
corresponding non-dwo sections.

> While we are at it and preparing DWARF6 it would be a great hint to tool
> developers to know where they need to focus effort by keeping this table
> up to date with the evolving DWARF6.

I didn't add a column for DWARF6. I don't think we're close enough yet
to give any guidance there.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> > 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 is Gnu FDL, but the website itself (at least more recent stuff)
> > is CC-BY.
>
> Yeah I already talked to her about that. She's totally fine with that
> idea. She's not one who spends a lot of time worrying about the nuances
> of various licensing terms but rather has the practical outlook of
> someone who earns money as a creative. One of the less restrictive
> versions of CC makes sense. She usually turns over ownership in exchange
> for payment or considers it a work for hire but this would be a donation.

I did a little more reading on CC and found that they do not recommend
using a CC license for logos. I think we'd really just want the
copyright assigned to us.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> 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
> discuss font later.

Please give your wife my thanks -- she's done some great work here!

> As for the license, whatever. She slapped a CC-BY-SA on it based upon
> your previous email. She doesn't have a problem transferring ownership
> to whomever/whatever but I don't think that there is a legal entity that
> can possess it and I don't feel like we want to wade into all that
> entails. It is a favor, a donation to the community.

I've got no idea what the legal aspects are, so I'm just trying to be
extra careful. I'm sure as long as we have a clear record that she's
donating this to the DWARF committee, we should be OK.

Nonetheless, we'll definitely have to discuss this in the executive
committee, and/or the full committee. And it's not our highest
priority. Nevertheless, 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.

[Cary Coutant via Dwarf-discuss]

> 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 simply
> standardizes the existing behavior.
>
> In Section 2.2 Attribute Types, DW_AT_vector and
> DW_AT_variable_vector_width shall be added to Table 2.2
>
> 
> DW_AT_vector| A hardware vector register
> DW_AT_variable_vector_width | Array bound for hardware
> | implementation defined vector register
> | width
> 

I don't understand what tags this DW_AT_vector attribute would apply
to. Vector registers aren't *types*, they're *locations*, so it
doesn't really make sense to me to put this attribute on a
DW_TAG_array_type. We don't have DW_TAGs that describe registers; the
ABI defines the registers and DWARF producers and consumers should
understand and agree on the sizes and shapes of the various registers.

In Tony's proposal, the new attribute modifies a base type, thus
introducing a vector type, which might get placed in a vector
register. But there, I don't see how the vector base type is
fundamentally different from an array type. It seems it's just a dodge
to make it a base type so that we can put whole vectors on the stack.

Maybe what we're looking for is a DW_TAG_vector_type, whose DW_AT_type
attribute gives the base type for each element of the vector. This
seems to be more DWARF-like, and if we decide there's a reason to
allow stack entries with vector types, we can do that.

-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

[Cary Coutant via Dwarf-discuss]

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 encoding space for DWARF expression operations
> accommodates only 32 unique operations. In practice, the lack of a central
> registry and a desire for backwards compatibility means vendor extensions are
> never retired, even when standard versions are accepted into DWARF proper. 
> This
> has produced a situation where the effective encoding space available for new
> vendor extensions is miniscule today.
>
> To expand this encoding space we propose defining one DWARF operation in the
> official encoding space which acts as a "prefix" for vendor extensions. It is
> followed by a ULEB128 encoded vendor extension opcode, which is then followed
> by the operands of the corresponding vendor extension operation.
>
> This scheme opens up an infinite encoding space for arbitrary vendor
> extensions, and in practical terms is no less compact than if a fixed-size
> encoding were chosen, as was done for DW_LNS_extended_op. That is to say, when
> compared with an alternative scheme which encodes the opcode with a single
> unsigned byte: for the first 127 opcodes our approach is indistinguishable 
> from
> the alternative scheme; for the next 128 opcodes it requires one more byte 
> than
> that alternative scheme; and after 255 opcodes the alternative scheme is
> exhausted.
>
> Since vendor extension operations can have arbitrary semantics, the consumer
> must understand them to be able to continue evaluating the expression. The 
> only
> use for a size operand would be for a consumer that only needs to print the
> expression. Omitting a size operand makes the operation encoding more compact,
> and this was deemed more important than the limited printing use case.
> Therefore no ULEB128 size operand is present to provide the number of bytes of
> following operands, unlike DW_LNS_extended_op.
>
> A centralized registry of vendor extension opcodes which are in use, 
> maintained
> on the dwarfstd.org website or another suitable location, could also be
> implemented as a part of this proposal. This would remove the need for vendors
> to coordinate allocation themselves, and make it simpler to use more than one
> vendor extension at a time. As there is support for an infinite number of
> opcodes, the registration process could involve very limited review, and would
> therefore pose a minimal burden to the maintainer of such a registry.
>
> Proposal
> 
>
> 1) In Section 2.5.1.7, p38, add a new code at the end of the list:
>
> 3. DW_OP_user
> The DW_OP_user opcode encodes a vendor extension operation. It has at
> least one operand: a ULEB128 constant identifying a vendor extension
> operation. The remaining operands are defined by the vendor extension.
> The vendor extension opcode 0 is reserved and cannot be used by any
> vendor extension.
>
> The DW_OP_user encoding space can be understood to supplement the
> space defined by DW_OP_lo_user and DW_OP_hi_user that is allocated by
> the standard for the same purpose.
>
> 2) In Section 7.7.1, p226, add a new row to table 7.9:
>
> DW_OP_user  |  TBD  |  1+  | ULEB128 vendor extension opcode, followed by
> |   |  | vendor-extension-defined operands
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> 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: tensor types. V3

[Cary Coutant via Dwarf-discuss]

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 DWARF for GPUs meeting. Cary
> originally wanted it to be a TAG rather than an attribute on an array and
> quite frankly, I don't care and so my default position is "What Cary wants,
> Cary gets". However, Pedro pointed out LLVMs different flavors of vector
> types which like the vector types bubbled up from the target architecture
> to language source through intrinsics. Each of these different vectors
> flavors has slightly different semantics. There is a really nice table on
> https://clang.llvm.org/docs/LanguageExtensions.html#id15 that summarizes
> the differences. This changed the course of discussion and it seemed that
> the group moved back to making it an attribute on an array. Since there are
> multiple flavors of vector, this led to adding a parameter to the attribute
> that defines the flavor and a table which defines what those constants mean.
>
> I brought up the point about matrix registers. Jakub is right there are
> currently no compilers which make use of matrix vector types right now.
> Even AMD's GPUs which do have intrinsics for matrix operations end up
> implementing them with arrays of vector registers. This area is rapidly
> evolving due to its heavy use in HPC and AI. The challenge appears to be
> the compilers haven't supported these operations yet. Cary came up with the
> idea of calling it a "tensor" rather than defining DW_AT_vector and then
> later adding DW_AT_matrix. So through the entire document, vector has been
> changed to tensor.
>
> Markus pointed out a few problems in my V2 version, I tried to address
> those. They were pretty minor and obvious. Markus please verify that I did
> it to your satisfaction otherwise V4.
>
> What has not changed since V2:
>
> I didn't put back any changes that would allow these tensor types to
> appear on the DWARF stack. I feel that particular topic hasn't been settled
> yet. The general plan is I will work with Jakub and create some cases where
> a compiler could want to put these vector types on the DWARF stack. Tony
> Tye and the AMD team believe that the vector types do not need to be on the
> stack and believe that all the cases where the debuggers would want to
> access elements within the vector can be addressed with offsetting. IIUC a
> key point seems to be that they have never seen a case where an induction
> variable was embedded in a slot in a vector register, it always is a
> scalar. (I am not sure that I fully grokked their argument -- so please
> correct me) In the cases where it was, it could still be accessed as an
> implicit. Once I've got some examples of how a debugger might want to put
> vector types on the DWARF stack, the AMD team can suggest alternative
> approaches. I said that I would make a V4 proposal if the group ultimately
> comes to a consensus that vector registers are in fact needed on the stack.
>
> As for DWARF consumers, according to Cary, the reason why DWARF operations
> are currently limited to base types is to make it relatively easy on the
> consumers. If vector registers are in fact needed on the stack, Zoran is
> fairly certain that changes that he's preparing to enable gdb to support
> GPUs would also automatically handle vector registers on the stack. The
> problem for gdb would be client server operation with gdbserver. The goal
> with gdbserver has been to keep its execution footprint very small. While
> having huge registers on the DWARF stack is reasonable when gdb is
> operating on the target or on the client side, on the server end it may
> pose a problem. John DelSignore said that TotalView has a similar concern
> because of its client server architecture. He did point out though that
> DWARF expressions are ephemeral.
>
> My impression was that Cary wanted to add this tensor types issue to the
> DWARF issue queue for discussion and once question of vector registers on
> the stack is settled, this proposal can be amended or a new proposal
> addressing just that issue can be filed.
> --
> Tensor types
>
> Some languages support vector data types, which are not possible to
> represent today in standard DWARF.  A vector is an array of values.
> These can be allocated to a SIMD vector register, if available, either
> permanently or temporarily, and operations on vectors make use of SIMD
> instructions, again if available.
>
> For example, as an extension to C and C++, GCC supports defining
> vector data types as described here:
>
>   https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
>
> In this C/C++ extension, vector types are similar to arrays, and you
> can index and initialize them similarly, but they have some important
> differences.  For example:
>
> - C arr

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

[Cary Coutant via Dwarf-discuss]

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 described in https://www.modular.com/mojo.
>
>
> Proposed changes:
>
> [Section 3.1.1, pg 62, Table 3.1. Language Names] - Add
>
> DW_LANG_Mojo  Mojo
>
> [Section 7.12, Figure 7-17. Language Encodings] - Add
>
> DW_LANG_Mojo  0x0033  default lower bound = 0
>
>
> Sincerely,
>
> Walter Erquinigo
>
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> > 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 spaces in the name. I added a Debugging-using-
> DWARF-2012.pdf -> 'Debugging using DWARF-2012.pdf' symlink.

I've fixed the original link.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> 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.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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 <
dwarf-discuss@lists.dwarfstd.org> wrote:

> Hi Ben,
>
> On Mon, Jun 19, 2023 at 01:32:05PM -0700, Ben Woodard via Dwarf-discuss
> wrote:
> > Can we please add a link to the current evolving DWARF6 standard
> > working draft somewhere on https://dwarfstd.org/index.html
> >
> > I was wanting to show someone that we have the current working copy
> > that we produce and I was sure that you could navigate to it from
> > the main page but I was unable to find it that way. If it is there
> > (and I couldn’t find it) could we make it obvious?
>
> I don't know what the best place is to put a link, but the current
> draft can be found in git: https://git.dwarfstd.org/dwarf-spec
>
> There is a Makefile inside the latexdoc directory that will build you
> a PDF version.
>
> You can also find an automaticly generated snapshot at:
> https://snapshots.sourceware.org/dwarfstd/dwarf-spec/latest/
>
> Please note that these are of course WORKING DRAFTS (it says so on
> every page). There is a Change Summary that tells which Issues have
> been incorporated. But new issues can still change things.
>
> Also the changebars are currently missing. If someone with some latex
> knowledge knows how to get them to show up in the PDF version that
> would be appreciated.
>
> Cheers,
>
> Mark
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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 value
> had been computed on entry to the current subprogram. Its operand is
> either a DWARF expression, which assumes nothing is already on the
> DWARF stack and leaves one value on the DWARF stack; or, it is a
> register location description, and the content of the register (as it
> was on entry to the subprogram) is implicitly read and pushed on the
> DWARF stack. The register location description is simply a more compact
> representation of the common case of reading a register; for example,
> the producer can emit "DW_OP_reg1" instead of "DW_OP_breg1 0" with the
> same result.
>
> However, the description and examples aren't completely consistent, and
> in some cases are wrong. This proposal corrects the language and examples.
>
> ## Proposed Changes
>
> ### Section 2.5.1.7 Special Operations, p.37
>
> The first sentence of the description of DW_OP_entry_value reads:
>
> The DW_OP_entry_value operation pushes the value that the described
> location held upon entering the current subprogram.
>
> A DWARF expression does not describe a location, so this should read:
>
> The DW_OP_entry_value operation evaluates an expression or register
> location description as if it had been evaluated upon entering the
> current subprogram, and pushes the value of the expression or content
> of the register, respectively.
>
> ### Appendix D.1.3, pp.291-292
>
> There are six examples of DW_OP_entry_value, some of which are not
> consistent with the description and some of which are just plain wrong.
> The six examples are:
>
> DW_OP_entry_value 2 DW_OP_breg1 0
> DW_OP_entry_value 1 DW_OP_reg1
> DW_OP_entry_value 2 DW_OP_breg1 0 DW_OP_stack_value
> DW_OP_entry_value 1 DW_OP_reg1 DW_OP_stack_value
> DW_OP_entry_value 3 DW_OP_breg4 16 DW_OP_deref DW_OP_stack_value
> DW_OP_entry_value 1 DW_OP_reg5 DW_OP_plus_uconst 16
>
> The first two illustrate the smaller expression allowed by the special
> case for a register location description; they are fine.
>
> The third is just wrong and should be deleted. DW_OP_stack_value converts
> a memory location description into a value, but what precedes it is not
> a memory location description. Without the stack_value, it's identical to
> the first example.
>
> The fourth is just wrong and should be deleted. DW_OP_reg1 names a register
> but pushes nothing on the stack, so DW_OP_stack_value is incorrect; and
> without that, it's identical to the second example.
>
> The fifth should not have DW_OP_stack_value at the end; the expression
> already leaves a value on the stack.
>
> The sixth is incorrectly using DW_OP_reg5, which is allowed in a location
> description but not in a simple DWARF expression. The expression could be:
> DW_OP_entry_value 2 DW_OP_breg5 16
>
> The textual description of the sixth example should also be revised.
> Currently it reads:
> The address of the memory location is calculated by adding 16 to the
> value contained in register 5 upon erringing the current subprogram.
> Note that unlike the previous DW_OP_entry_value examples, this one
> does not end with DW_OP_stack_value.
>
> This should be changed to:
> Add 16 to the value register 5 had upon entering the current subprogram
> and push the result.
>
> (The italicized text after the sixth example should be removed entirely;
> there is no reason ever to use DW_OP_stack_value in these expressions.)
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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`
>
> ## Background
>
> Local type unit entries in `.debug_names` reference type units via their 
> offset in the `.debug_info` section.
>
> Assuming a non-DWARF-aware linker, per 6.1.1.3: "When linking object files 
> containing per-CU indexes, the linker may choose to concatenate the indexes 
> as ordinary sections ..."
>
> If a linker does this, it will need to choose what value to resolve a 
> relocation for the TU offset to, if that TU was discarded. (if the TUs are 
> bit identical, the linker might resolve all relocations to identical copies 
> to refer to the remaining copy - but TUs aren't guaranteed to be byte 
> identical - and since the offsets in the `.debug_names` table refer to 
> specific byte offset in the TU, these entries can't be used if a 
> different-but-equivalent copy of the TU is the one that's preserved by the 
> linker)
>
> To deal with this, the linker would use a tombstone value of some kind to 
> indicate that the offset couldn't be resolved. By default, this offset might 
> be zero - which is a valid offset within the `.debug_info` section, and would 
> not be possible for the DWARF consumer to differentiate the "ignore this 
> index entry" from a valid index entry pointing to a TU at offset zero.
>
> With https://dwarfstd.org/issues/200609.1.html we chose a tombstone value for 
> other cases (.debug_info referencing into code - in the case of discarded 
> functions) of "the largest representable value". This seems like a good 
> foundation for addressing this new, similar case.
>
> ## Proposed Changes
>
> Add a paragraph between the first and second/last in 6.1.1.4.3 that reads:
>
> "Any local TU entry with a maximum representable value is considered not 
> present. Any index entry referencing such a local TU entry should be ignored."
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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 describes this policy. For the
> producers it explicitly reserves some of the valid values for encoding
> various constructs and promises not to use those values in future versions
> of the standard. Consumers are given the freedom and expected to skip over
> data that they do not recognize.
>
> The original intent of these vendor extensions was that they would be a
> private agreement between a particular producer and a cooperating consumer.
> However, the range of tools expanded beyond a toolchain provided by a
> single vendor and so the concept of a private agreement between a specific
> producer and a cooperating consumer came to be regarded as a registry of
> vendor extensions that every tool must be aware of for the sake of
> compatibility.
>
> Because compatibility between tools was prioritized, the extensions in
> these de facto registries were effectively considered permanent unofficial
> DWARF encodings. This presumptive permanence is in spite of the fact that
> in some cases:
>
>-
>
>Producers that made use of these extensions were never implemented or
>publicly released.
>-
>
>Producers that made use of these extensions are so obsolete that not
>only does the tool chain no longer exist but the hardware that this
>toolchain was designed for no longer exists except as historical artifacts.
>-
>
>Official versions of DWARF encodings that accomplish the same thing
>have been added to the standard making the vendor extension obsolete.
>
>
> The accumulation of these vendor extensions over the years has led to
> problems with some DWARF constructs where they are running out of available
> encodings that do not overlap with the ones used by or reserved by the
> standard. In particular the range of vendor vendor extension encoding is
> running particularly short in the range of DW_OP encoding. This has led to
> several informal proposals within the vendor community along the lines of
> an official proposal 230324.1 Expression Operation Vendor Extensibility
> Opcode https://dwarfstd.org/issues/230324.1.html The basic idea in most
> of these proposals is to extend the range of available vendor extension
> encodings. While DWARF expression operations, Section 2.5, has the most
> extreme shortage of vendor encodings, other DWARF constructs are also
> running out of usable encodings.
> Overview
>
> This proposal is an alternative to 230324.1 and similar informal
> approaches to increase the available encoding space. It does this in two
> ways.
>
> First it makes it explicit that Vendor Extensions can only be interpreted
> in the context of a particular producer and a DWARF standard version. This
> way obsolete vendor extensions can be retired when a new version of the
> standard is released. It also begins the process of replacing the
> expectation for consumers that they can simply ignore encodings that they
> do not understand with the expectation they will need to have producer and
> version awareness when interpreting encodings. This is because tools chains
> are no longer developed by a close knit group of developers who all work
> for a single vendor. Tools are now developed by diverse distributed teams
> and users need and rightly expect interoperability.
>
> Because the bulk of tool development is no longer done by vendors who
> build a vertically integrated tool chain but rather is done by looser
> confederation of projects that need to cooperate to achieve compatibility,
> the term “vendor” is replaced with more generic terms when referring to
> these extensions.
>
> The second big change is it seeks to foster compatibility and
> collaboration by taking the collection of informal registries such as
> https://sourceware.org/elfutils/DwarfExtensions and
> https://llvm.org/docs/SourceLevelDebugging.html#new-dwarf-tags and
> collects them and brings them under the aegis of the DWARF standards body.
> To facilitate innovation and quickly meet producer’s and consumer’s needs
> the expectation is that registering a new producer specific construct and
> encoding would be a simple, light weight or even partially automated task.
> It would not be at all like amending the standard. The registry would be
> published on the DWARF standard’s web site so that consumers can easily
> find it. Each extension would be listed along with the producers that emit
> it and the range of DWARF standard versions that it applies to. When new
> DWARF standard versions are released, each extension will be reconsidered
> to see if it continues to add utility in the context of the new version of
> the DWARF standard. Extensions that persist over several versions of the
> DWARF standard probably should be

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

[Cary Coutant via Dwarf-discuss]

> 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, Table 7.17. Language Encodings] - Add
>
> DW_LNAME_Ruby 0x0026 0

Thanks for the submission! This is issue 231230.1:

https://dwarfstd.org/issues/231230.1.html

I've assigned language codes for both DWARF 5 and DWARF 6 as follows:

DW_LANG_Ruby 0x0040
DW_LNAME_Ruby 0x0026

For DW_LNAME_Ruby, I gave it the version scheme VVMM, which seems to
match the version numbering system used for Ruby releases; please let
me know if that's not the right scheme to use. The default lower bound
for array indexing is 0.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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. During the discussion of 
> that issue, the question came up of whether all tables allowed padding, so 
> that contiguous concatenated contributions could be aligned reasonably. This 
> is the result of my research.
>
> ## Overview
>
> The set of tables (merging the two tables from 230329.1) is as follows:
>
> - .debug_abbrev / .debug_abbrev.dwo (Section 7.5.3)
> - .debug_aranges (Section 6.1.2)
> - .debug_addr (Section 7.27)
> - .debug_frame (Section 6.4.1)
> - .debug_info / .debug_info.dwo (Section 7.5.1)
> - .debug_line / .debug_line.dwo  (Section 6.2.4)
> - .debug_line_str
> - .debug_loclists / .debug_loclists.dwo (Section 7.29)
> - .debug_macro / .debug_macro.dwo (Section 6.3.1)
> - .debug_names (Section 6.1.1)
> - .debug_rnglists / .debug_rnglists.dwo (Section 7.28)
> - .debug_str / .debug_str.dwo
> - .debug_str_offsets / .debug_str_offsets.dwo (Section 7.26)
>
> ### .debug_abbrev
>
> Entries have arbitrary size. Can be padded by adding an unused abbrev entry. 
> Proposing a non-normative paragraph describing this.
>
> ### .debug_aranges
>
> Removed by 220724.1.
>
> ### .debug_addr
>
> Entries have a size of (segment_selector_size + address_size) and don't 
> explicitly provide a padding mechanism. Adding unused entries at the end of 
> the table should suffice. Proposing a non-normative paragraph describing this.
>
> ### .debug_frame
>
> Already permits padding by use of DW_CFA_nop.
>
> ### .debug_info
>
> Already permits padding by use of the abbreviation code 0 (see Section 7.5.2).
>
> ### .debug_line
>
> Already has DW_LNE_padding.
>
> ### .debug_line_str
>
> This is a string section and does not need padding (typically would be 
> merged, not concatenated).
>
> ### .debug_loclists
>
> Already permits padding by use of repeated DW_LLE_end_of_list, with a 
> non-normative comment to that effect.
>
> ### .debug_macro
>
> This has no unit_length and no explicit provision for padding. One could 
> insert unused opcodes into the opcode_operands_table but this seems like 
> quite a hack. In keeping with other sections, I'm proposing a 
> DW_MACRO_padding opcode.
>
> ### .debug_names
>
> Components are mostly 4- or 8-byte multiples, except for the abbreviation 
> table. The abbreviation table explicitly permits padding (Section 6.1.1.4.7).
>
> ### .debug_rnglists
>
> Already permits padding by use of repeated DW_RLE_end_of_list, with a 
> non-normative comment to that effect.
>
> ### .debug_str
>
> This is a string section and does not need padding (typically would be 
> merged, not concatenated).
>
> ### .debug_str_offsets
>
> This has a header of 8 or 16 bytes, and entries of 4 or 8 bytes. This can 
> still require padding if you want alignment greater than 4 bytes, and there 
> is no explicit provision. Proposing a non-normative paragraph describing this.
>
> ### Conclusion
>
> Everything is already covered except .debug_abbrev, .debug_addr, 
> .debug_str_offsets, and .debug_macro. The first three need non-normative 
> notes describing how to pad the sections, and .debug_macro requires a new 
> opcode to introduce padding cleanly.
>
> ## Proposed Changes
>
> I sorted these by affected section. In addition to the section-specific 
> changes there is one general note.
>
> ### .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 
> flag, and two 0 bytes indicating the end of the attribute/form pairs). This 
> can be expanded by choosing a large abbreviation number with a longer LEB128 
> encoding, or adding non-zero attribute/form pairs.*
>
> ### .debug_macro
>
> Add new Section 6.3.4 "Other Entries" (~ p.170) as follows:
>
> 1. DW_MACRO_padding
>The DW_MACRO_padding opcode takes two operands, a byte count and a sequence
>of arbitrary bytes. The byte count is an unsigned LEB128 encoded number and
>does not include the size of the opcode or the byte count operand. The 
> opcode
>and operands have no effect on the macro information.
>
>*This permits a producer to pad the macro information with a minimum of 
> two bytes.*
>
> ### .debug_str_offsets
>
> In Section 7.26 "String Offsets Table" (p.241), at the end of the section, 
> add a new non-normative paragraph:
>
> *This table may be padded with unused entries to fill out the table to some 
> desired alignment. These entries should have all 1 bits as a hint that the 
> entries are unused.*
>
> ### .debug_addr
>
> In Section 7.27 "Address Table" (p.241), at the end of the section, add a new 
> non-normative par

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

[Cary Coutant via Dwarf-discuss]

> ### .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 
> flag, and two 0 bytes indicating the end of the attribute/form pairs). This 
> can be expanded by choosing a large abbreviation number with a longer LEB128 
> encoding, or adding non-zero attribute/form pairs.*

Couldn't the abbrev table simply be padded with 0 bytes?

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> 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 language codes DW_LANG_Move = 0x0041 and
DW_LNAME_Move = 0x0027.

No version scheme specified yet. Please let us know if you'd like to
specify a version scheme (see https://dwarfstd.org/languages-v6.html).

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> 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://dwarfstd.org/issues/240213.1.html

Assigned new language code DW_LANG_Hylo = 0x0042, DW_LNAME_Hylo =
0x0028. Assuming default lower bound = 0.

No version scheme specified yet. Please let us know if you'd like to
specify a version scheme (see https://dwarfstd.org/languages-v6.html).

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> 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 undefined.
>
> I propose adding similar language to the description of DW_OP_piece. e.g.

This has been clarified for DWARF 6; see:

https://dwarfstd.org/issues/181205.1.html

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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 alternative proposal,
> but I'm fine with Zoran taking it over if he wants to.
>
> # Describe prologue and epilogue ranges
>

I've added this as Issue 240318.1
.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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 eliminate a substantial number of those relocations. In fact, parts of
the split DWARF series of proposals in DWARF 5 were all about minimizing
the quantity of relocations (e.g., DW_FORM_addrx and DW_FORM_strx).

This proposal adds an indirect string form to the name table (for use when
a non-split DWARF compilation is already using .debug_str_offsets), and a
local string pool in the name table (for use in a split-DWARF compilation).

-cary
 Add Local and Indirect Strings to Name IndexBackground

The name table in the .debug_names section currently references strings via
offsets to the .debug_str section. Each string offset, therefore, requires
a relocation unless some under-the-table agreement is made between the
compiler and linker. This can get expensive, as the number of names can be
quite large.

For non-split DWARF, the use of .debug_str makes sense, as many or most of
the names in the name index are also referenced from entries in the
.debug_info section. If the .debug_info section is using DW_FORM_strx and a
.debug_str_offsets section, however, it would also be beneficial for the
name index to use string references in the style ofDW_FORM_strx, which
would eliminate the need for any relocations in the name table.

For split DWARF, there is little overlap between the strings referenced by
the skeleton .debug_info section and those referenced by the
.debug_names section,
and there is no advantage gained by storing the strings in the separate
section.
Overview

This proposal adds two alternative string representations to the name
index: one in the style of DW_FORM_strx for non-split DWARF compilation
units that use .debug_str_offsets, and one with a local string table stored
directly in the .debug_namessection that requires no relocations.
Proposed Changes

In Section 6.1.1.2 Structure of the Name Index, change “eight individual
parts” to “nine individual parts,” and add the following to the enumerated
list of parts between items 6 and 7:


   1. An optional local string pool.

(Renumber the last two items.)

In Figure 6.1 Name Index Layout (part 1), under “Name Index”, add a box for
“Local String Pool” between “Name Table” and “Abbrev Table”. The box
expands to a box on the right labeled “Strings”.

Also in Figure 6.1 Name Index Layout (part 1), change “String Offsets” to
“String Pointers or Indexes” in the expansion of “Name Table”.

In Section 6.1.1.4.1 Section Header, replace field 3 (“padding”) with the
following:


   1.

   str_format (ubyte)

   An enumerated constant that specifies the representation of string
   references in the name index. The possible values are: DW_FORM_strp,
   DW_FORM_strp8, and DW_FORM_strx4 (see Section 7.5.5 Classes and Forms).
   2.

   padding (ubyte)

   Reserved to DWARF (must be zero).

Renumber fields 4-8, and add the following fields after “name_count”:


   1.

   local_str_pool_size (uword)

   Size of the local string pool. If this value is non-zero, string offsets
   (when str_format is DW_FORM_strp or DW_FORM_strp8) reference the local
   string pool. If this value is 0, string offsets reference the .debug_str
   section. If str_format is DW_FORM_strx4, this field should be 0.
   2.

   str_offsets (section offset)

   A 4-byte or 8-byte unsigned offset that points to the header of the
   compilation unit’s contribution to the .debug_str_offsets section.
   Indirect string references (when str_format is DW_FORM_strx4) are
   interpreted as zero-based indexes into the array of offsets following the
   header. If str_format is DW_FORM_strp or DW_FORM_strp8, this field
   should be 0.

In Section 6.1.1.4.6 Name Table, replace the first paragraph with the
following:

The name table immediately follows the hash lookup table. It consists of
two arrays: an array of string pointers or indexes, followed immediately by
an array of entry offsets. The items in the first array are determined by
the str_format field in the section header, and may be 4-byte or 8-byte
offsets into either the .debug_str section or the local string pool, or
4-byte indexes into the array of offsets in the .debug_str_offsets section.
The items in the second array are section offsets: 4-byte unsigned integers
for the DWARF-32 format or 8-byte unsigned integers for the DWARF-64
format. The entry offsets in the second array refer to index entries, and
are relative to the start of the entry pool area.

Following Section 6.1.1.4.6, add a new section:

Section 6.1.1.4.7 Local String Pool

The local string pool, if present, immediately follows the name table. It
consists of a series of null-terminated strings. Its size is given by
local_str_pool_size.

[non-normative] *For non-split DWARF compilation units, 

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

[Cary Coutant via Dwarf-discuss]

>
> 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 eliminate a substantial number of those relocations. In fact, parts of
> the split DWARF series of proposals in DWARF 5 were all about minimizing
> the quantity of relocations (e.g., DW_FORM_addrx and DW_FORM_strx).
>
> This proposal adds an indirect string form to the name table (for use when
> a non-split DWARF compilation is already using .debug_str_offsets), and a
> local string pool in the name table (for use in a split-DWARF compilation).
>

This is proposal 240320.1 .

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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 correctly. The non-normative text at
the beginning of Section 6.2 says:

> We shrink it with two techniques. First, we delete from the matrix each
> row whose file, line, source column and discriminator is identical with
> that of its predecessors. Any deleted row would never be the beginning
> of a source statement. Second, ….

This isn't quite right — the `is_stmt` flag doesn't mark the beginning of
a source statement; it marks a suggested breakpoint location, which may
not be the first instruction of the statement. So it's quite possible
that a row with `is_stmt = false` could be followed by a row with `is_stmt
= true`, whose file, line, source column, and discriminator are identical
with the first. So really, we should say that no row where `is_stmt =
true` can be deleted. Likewise, `prologue_end` and `epilogue_begin` have the
same effect — they apply to a single instruction, but not to the
instructions in any following rows that were elided.

## Proposed Changes

In Section 6.2, replace the sentences quoted above with the following:

> We shrink it with two techniques. First, we delete from the matrix each
> row whose file, line, source column and discriminator is identical with
> that of its predecessors, except where the instruction is marked as
> a suggested breakpoint location, the end of a prologue region, or the
> beginning of an epilogue region. Second, …..
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

>
> 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.
>
> Anyway, I'll fix it for V6.
>
> The next available code is 0x0027. What makes you think the code should be
> 0x0029?
>
>
> I was looking at https://dwarfstd.org/languages-v6.html where the last
> assigned langiage is DW_LNAME_Hylo 0x0028.
>

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.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

>
>
> 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 been following Michael's protocol of using the status "Language Code
Assigned" for new language codes, where no committee discussion is
necessary. Would it help your process if I added the word "Accepted" to the
issue status?

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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/languages-v6.html does not
> list a version scheme for the Swift language. This proposal adds one.
>
> ## Overview
>
> The Swift programming language does not have a version scheme defined for
> DW_AT_language_version. This proposal defines it to use the `VVMM` version
> scheme. This way "Swift 5.10" would be
>
> ```
> DW_AT_language(DW_LANG_Swift)
> DW_AT_language_version(510)
> ```
>
> and "Swift 6" would be `DW_AT_language_version(600)`. Even though Swift
> package releases usually have a Major.Minor.Patch version scheme (e.g.,
> Swift 5.9.2), the Swift compiler frontend's LangOptions data structure only
> uses Major.Minor to distinguish syntax changes in the parser (see
> References). This version scheme is designed to match what the compiler
> does.
>
> ## Proposed Changes
>
> Augment the table of language encodings to say
>
> ```
> Swift DW_LNAME_Swift 0x001a 0 VVMM
> ```
>
> ## Dependencies
>
> Issue 210419.1
>
> ## References
>
> https://www.swift.org/download/ (see older releases for a history of
> versions).
>
> https://github.com/apple/swift/blob/3d32f5fc8a9087add424a2704ef1dcd89c9307ff/include/swift/Basic/LangOptions.h#L174
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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/languages-v6.html does not
> list a versioning scheme for Fortran, but we have DWARF 5 language
> constants for FORTRAN77 through Fortran08.
>
> ## Proposed Changes
>
> Augment the table of language encodings to add `` to Fortran as a
> version scheme.
>
> ## Dependencies
>
> Issue 210419.1
>
> ## References
>
> https://dwarfstd.org/languages-v6.html
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

>
>
> >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 just leave well-enough alone. I just updated
> the document to match the website (and make DW_LNAME_HIP = 0x0029). So any
> change causes work for me. Similarly it creates work for anyone who is
> actually trying to use code DW_LNAME_Assembly. Why bother?
>

Looks like DW_LNAME_HIP never made it into the document after it was
approved. Given the timing, it would make a little more sense to renumber
Assembly instead, but since that's already in the document, and HIP isn't,
I'll renumber HIP. Since this affects the DWARF 6 language codes only, we
shouldn't have to worry about affecting anyone. Heads up, though: if anyone
has started using DW_LNAME_HIP, please be aware of this change!

I've added this as Issue 240423.1
.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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:
> > # C standard release dates for DW_AT_language_version, clarify semantics
> >
> > ## Background
> >
> > The list of languages at https://dwarfstd.org/languages-v6.html does
> not list release dates for the ISO C standard. Producers need to know what
> version numbers they should produce though. I scanned the ISO website for
> appropriate dates to use.
> >
> > ## Proposed Changes
> >
> > Augment the table of language encodings to add
> > C (K&R and ISO) DW_LNAME_C 0x0003 0 MM
> >
> > K&R 00
> > C89 198912
> > C99 199912
> > C11 201112
> > C17 201806 (sic!)
> > C2x >201806
>
> That is not correct.
> C99 199901
> C11 201112
> C17 201710
> C23 202311
>
> C89 with ammendment 1 would be
> 199409
> C89 likely that 198912 indeed.
>
> As for C++, the above page is missing
> C++23 202302
> >
> > Add the following non-normative wording:
> >
> > To convert a version number to a specific release, it is good practice
> to treat the YYYMM version numbers listed in this document as the maximum
> version that is interpreted as belonging to a specific release.
>
> > This way consumers can emit version numbers for unreleased upcoming
> specifications, by using, e.g., the date the compiler was built.
>
> That is not a good suggestion.
> If a compiler supports some part of e.g. C23 but not everything, it should
> be something larger than 201710 but smaller than 202311, even when the date
> the compiler was built could be 202404 or later.
> GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations,
> GCC still does, Clang 18+ now uses 202311.
>
> Jakub
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

>
> 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 information is
> presented in the Agenda for a meeting that would probably suffice, although
> it is the minutes that should be complete and definitive.
>

Good idea. I'll do that.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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
>property MyProp: integer read public MyFunc write MyMember; default;
>
> As I added the  DW_AT_Default_Property flag in the example.
> In FreePascal, this would currently only be valid for properties with
> array-indexes, but may be extended in future. For the example it just
> shows where the attribute would go.
>
>
>
> On 08/05/2024 12:35, Martin via Dwarf-discuss wrote:
> > Here are 2 examples of what it would look like
> >
> > ## Property with different visibility
> >
> > ```
> >type
> >  TFoo = class
> >  private
> >MyMember: integer;
> >function MyFunc: integer;
> >  protected
> >// "read public" is currently from oxygene, but may be added to
> > FreePascal
> >property MyProp: integer read public MyFunc write MyMember;
> >  end;
> >
> >  TBar = clall(TFoo)
> >  public
> >property MyProp; // elevate to public
> >  end;
> > ```
> >
> > ```
> >DW_TAG_Structure_type
> >  DW_AT_Name :  "TFoo"
> > L1:
> >  DW_TAG_Member
> >  DW_AT_Name:  "MyMember"
> >  DW_AT_Type:  <...>
> >  DW_AT_Member_location :  <...>
> > L2:
> >  DW_TAG_subprogram
> >  DW_AT_Name:  "MyFunc"
> >  DW_AT_Type:  <...>
> >
> >  DW_TAG_Property
> >  DW_AT_Name :  "MyProp"
> >  DW_AT_Type :  <...>
> >  DW_AT_Accessibility:  DW_ACCESS_protected
> >  DW_AT_Default_Property :  TRUE
> >DW_TAG_Property_Getter
> >DW_AT_Property_Forward :  reference to L2
> >DW_AT_Accessibility:  DW_ACCESS_public
> >DW_TAG_Property_Setter
> >DW_AT_Property_Forward :  reference to L1
> >
> >DW_TAG_Structure_type
> >  DW_AT_Name :  "TBar"
> >  DW_TAG_Inheritance
> >  <...>
> >  DW_TAG_Property
> >  DW_AT_Name :  "MyProp"
> >  DW_AT_Accessibility:  DW_ACCESS_public
> > ```
> >
> > ## Property with access to nested field
> >
> >
> > ```
> >type
> >  TFoo = class
> >OtherData: DWORD;
> >FNested: record
> >  MyMember: integer;
> >end;
> >property MyProp: integer read FNested.MyMember;
> >  end;
> > ```
> >
> > ```
> > L1:
> >DW_TAG_Structure_type
> > L2:
> >  DW_TAG_Member
> >  DW_AT_Name:  "MyMember"
> >  DW_AT_Type:  <...>
> >  DW_AT_Member_location :  <...>! inside FNested
> >
> >DW_TAG_Structure_type
> >  DW_AT_Name :  "TFoo"
> >  DW_TAG_Member
> >  DW_AT_Name :  "OtherData"
> >  DW_TAG_Member
> >  DW_AT_Name :  "FNested"
> >  DW_AT_Type:  reference to L1
> >  DW_AT_Member_location :
> >DW_OP_plus_uconst 4 ! where 4 == offset of
> > MyMember in the instance data
> >
> >  DW_TAG_Property
> >  DW_AT_Name :  "MyProp"
> >  DW_AT_Type :  <...>
> >DW_TAG_Property_Getter
> >DW_AT_Property_Forward :  reference to L2
> >DW_AT_Property_Object  :
> >DW_OP_push_object_address  ! maybe should be on stack by
> > default
> >DW_OP_plus_uconst 4! where 4 == offset of
> > MyMember in the instance data
> >   ! There could be several
> > levels of nesting, so that expression could be more complex
> > ```
> >
> > In the example the property does not have a reference to FNested itself.
> > All it needs is the object_address of FNested, so it can calculate the
> > location of the referenced field MyMember (using the member_location).
> >
> >
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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].
>
> [1]
> https://herbsutter.com/2023/02/13/c23-pandemic-edition-is-complete-trip-report-winter-iso-c-standards-meeting-issaquah-wa-usa/


This is issue 260616.1 . For
DWARF 5, I will also add DW_LANG_C_plus_plus_23, with the value 0x003a.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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 is sometimes
> mentioned as being part of a split-full compilation
> unit and yet other places say that is incorrect.
> In other words the standard conflicts with itself.
>
> There is clarity in Sec 3.1.2 Skeleton Compil...
> Page 66,67:
> (lists a few attributes, not including
> DW_AT_rnglists_base)
> "All other attributes of a compilation unit
> entry are placed in the split full compilation unit."
> (comment: this makes Table F.1 incorrect)
>
> Sec 3.1.3 says DW_AT_rnglists_base is inherited
> from the skeleton. That is wrong and corrected
> in DW6.
>
> Table F.1
> DW5 has no check mark for DW_AT_rnglists_base
> in Skelton or Split Full
> Wrong.
>
> Table F.1
> DW6 has check mark for DW_AT_rnglists_base
> in Skeleton but not Split Full.
> Wrong.
>
>
> PROPOSAL:
>
> Table F.1, for DW_AT_rnglists_base
> should have:
> No check-mark for Skeleton.
> One check-mark for Split Full.
> (the check-mark for Full & Partial
> is correct in DW5 and DW6)
>
>
>
> David Anderson
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: rnglists_base missing

[Cary Coutant via Dwarf-discuss]

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_rnglistx
> is a DW_AT_rnglists_base required?
> Apparently not, though
> in cases I have seen in object files are instances
> of a single rnglist in .debug_rnglists.dwo .
> The operative assumption is consumers will
> simply assume zero as the (missing)
> DW_AT_rnglists_base.
>
> Seen in llvm and gcc.
>
> The intent of this proposal is to get clarity.
>
> An alternative version could state
> If a Split Full Compilation Unit
> refers to .debug_rnglists.dwo
> with  DW_FORM_rnglistx
> the CU DIE must have a DW_AT_rnglists_base
> attribute.
>
>
> PROPOSAL:
>
> At the end Sec F.1 Overview just before
> Table F.1:
>
> If a Split Full Compilation Unit
> refers to .debug_rnglists.dwo
> with  DW_FORM_rnglistx
> and the correct DW_AT_rnglists_base
> would be zero, the DW_AT_rnglists_base
> may be omitted.
>
> David Anderson
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> On behalf of the Odin language community I’d like to file this enhancement
> proposal.
>
> # DW_LANG_Odin for the Odin Language
>
> ## Background
>
> In order to allow developing proper debug information for the Odin
> language, we request a DW_LANG_* code for the Odin language.
>
> ## Overview
>
> Please add DW_LANG_Odin to the specification. The Odin language is
> described at https://odin-lang.org/
>
> ## Proposed changes
>
> In section 7.12, Figure 7-17. Language Encodings, add
> DW_LANG_Odin, 0x0043, default lower bound = 0
>
> In section 3.1.1, Table 3.1. Language Names, add DW_LANG_Odin, Odin to the
> list of supported languages.
>
>
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
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`

[Cary Coutant via Dwarf-discuss]

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 source languages, it is possible for many program-counter
> addresses with arbitrary
> separation to correspond to the same source line due to features like
> templates/generics. When
> designing an incremental compiler, the line number program must be
> updated when line numbers within
> a source file are moved. It would be desirable to have the property that
> when moving a source line
> corresponding to a large amount of distinct program-counter addresses,
> only one line number value in
> the DWARF information needs to be updated. For this to be true, the
> regions of the line number
> program corresponding to each such address must include the line number
> of the source construct not
> directly, but through an indirect reference. This allows one line number
> value stored in the binary
> to be shared across arbitrarily many entries in the line number matrix.
>
> This is not currently possible: all modifications to the `line` register
> are given by relative
> offsets, and all of these offsets are directly included in the
> instruction (or implicit in the case
> of a special opcode).
>
> ## Overview
>
> Introduce new fields to the line number program header,
> `indirect_lines_length` (ULEB128) and
> `indirect_lines` (opaque block of bytes containing ULEB128 values). The
> `indirect_lines_length`
> field is the length in bytes of the `indirect_lines` section, rather
> than the number of elements.
> Introduce a new standard opcode to the line number program,
> `DW_LNS_indirect_line`. This opcode
> takes a single ULEB128 operand, which represents a byte offset into the
> `indirect_lines` stored in
> the header. The effect of this instruction is to set the `line` register
> to the ULEB128 value stored
> at the given byte offset into `indirect_lines`. Note that
> `indirect_lines` is not itself validated
> to be a valid sequence of ULEB128 values; decoding only occurs when
> `DW_LNS_indirect_line` is used.
> This allows an incremental compiler to pre-allocate a large amount of
> padding space in
> `indirect_lines` to fill in later as needed.
>
> Note that an incremental compiler would not necessarily wish to use
> variable-length integers to
> represent this information, since certain changes of line numbers could
> cause a line number which
> was previously encoded using 1 byte to now require 2. However, since the
> stored values need not be
> densely packed, an implementation is free to reserve as much space as is
> necessary for each entry.
> For instance, the downstream Zig compiler (which is the original
> motivator for this proposal) may
> choose to reserve 4 or 5 bytes for each line number, as line numbers in
> Zig source files cannot
> exceed 1<<32. The use of ULEB128 allows the compiler to make an
> appropriate decision here instead of
> codifying such a restriction into the DWARF specification.
>
> ## Proposed Changes
>
> Pages and line numbers are given for the 2024-06-16 working draft of
> DWARF Version 6, which is the
> latest draft at the time of writing.
>
> 6.2.4 (pg 163; line 27)
>
> 21. indirect_lines_length (ULEB128)
>  The length in bytes of the data stored in the `indirect_lines` field.
> 22. indirect_lines (block containing ULEB128 entries)
>  A collection of line numbers, each stored as a ULEB128 integer.
> These values are referenced by
>  DW_LNS_indirect_line instructions to modify the state of the line
> number information state
>  machine.
>
>  The data stored in this field is not checked to be a valid sequence
> of ULEB128 entries. The
>  contained data may include padding bytes or otherwise invalid data.
> As such, it is expected that
>  bytes of this field be accessed only when a DW_LNS_indirect_line
> instruction references them.
>
> 6.2.5.2 (pg 170; line 23)
>
> 14. DW_LNS_indirect_line
>  The DW_LNS_indirect_line opcode takes a single unsigned LEB128
> operand. This operand is
>  interpreted as a byte offset into the `indirect_lines` field of the
> line number program header.
>  An unsigned LEB128 value is read from `indirect_lines` at the given
> offset, and this value is
>  stored into the state machine's `line` register.
>
> 7.22 (pg 246; table 7.25)
>
>   Opcode name  | Value
> --+---
> ...|  ...
> DW_LNS_indirect_line  | 0x0d
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> 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] Dwarf language code for P4 langauge

[Cary Coutant via Dwarf-discuss]

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 list as that’s what we use for the record of requests.
>
> --paulr
>
>
>
> *From:* Chris Dodd 
> *Sent:* Sunday, July 28, 2024 1:38 AM
> *To:* Robinson, Paul 
> *Subject:* Re: [Dwarf-discuss] Dwarf language code for P4 langauge
>
>
>
> For P4, the lower bound for arrays is 0, and the versioning scheme is
> VVMMPP (current latest version is 010204 - 1.2.4 published last year though
> there will likely soon be a 1.2.5 version)
>
>
>
> On Sat, Jul 27, 2024 at 1:46 AM Robinson, Paul 
> wrote:
>
> It’s not written down anywhere (probably should be) but in order to assign
> a new language code, we need some additional information. Specifically, we
> need a default lower bound for arrays (as seen at
> https://dwarfstd.org/languages.html
> 
> ) and for the upcoming DWARF v6, a versioning scheme (as seen at
> https://dwarfstd.org/languages-v6.html
> 
> ).
>
> --paulr
>
>
>
> *From:* Dwarf-discuss  sony@lists.dwarfstd.org> *On Behalf Of *Chris Dodd via Dwarf-discuss
> *Sent:* Thursday, July 25, 2024 8:52 PM
> *To:* dwarf-discuss@lists.dwarfstd.org
> *Subject:* [Dwarf-discuss] Dwarf language code for P4 langauge
>
>
>
>
>
> I'd like to request the allocation of a new language code for the P4
> language (https://p4.org/
> ).
> Is there a standard process for this, or a different place it should be
> requested?
>
>
>
> Chris Dodd
>
> cd...@nvidia.com
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

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 30, 2024 at 6:22 PM Alexandre Oliva via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> On Jul 29, 2024, David Blaikie  wrote:
>
> >> The situation is not very different, but in Ada one can specify the
> >> target size (in bits) for the type (which may require biased
> >> representations, but that's besides the point).  Despite the specified
> >> size, standalone variables and members of unpacked types use full
> >> storage units, unless packing is requested.  See
> >> e.g.
> >>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gnat.dg/bias1.adb
>
> > I see, so do I understand correctly that you'd prefer not to use the
> > bitfield style representation, because it'd be repetitious?
>
> There's that (Dwarf aims for compactness), but there's also the fact
> that the type size is explicitly specified as the smaller bit size, so a
> proper representation of that type would carry that piece of
> information.  ISTM that ideally the larger, full-unit-sized variant
> would be the one using explicit sizes or a separate type variant
> inheriting the same bounds.
>
> But the problem I see, and try to raise in this thread, is that there's
> no way for a subrange type to inherit bounds from another subrange type,
> which once again plays against compactness.
>
> --
> Alexandre Oliva, happy hacker
> https://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but
> very few check the facts.  Think Assange & Stallman.  The empires strike
> back
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
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`

[Cary Coutant via Dwarf-discuss]

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 it to be worthwhile.

This could be prototyped as a producer extension by using extended line
table opcodes to build the `indirect_lines` table (in the same way that
`DW_LNE_define_file` could be used in DWARF 4 to build the `file_names`
table), or by splitting the indirect table into a separate section.

In any case, it was suggested that `DW_LNS_indirect_line` should be an
extended opcode, as its use is not expected to be common enough (across all
use cases) to warrant a standard opcode.

-cary


On Mon, Jul 1, 2024 at 7:56 PM Cary Coutant  wrote:

> 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 source languages, it is possible for many program-counter
>> addresses with arbitrary
>> separation to correspond to the same source line due to features like
>> templates/generics. When
>> designing an incremental compiler, the line number program must be
>> updated when line numbers within
>> a source file are moved. It would be desirable to have the property that
>> when moving a source line
>> corresponding to a large amount of distinct program-counter addresses,
>> only one line number value in
>> the DWARF information needs to be updated. For this to be true, the
>> regions of the line number
>> program corresponding to each such address must include the line number
>> of the source construct not
>> directly, but through an indirect reference. This allows one line number
>> value stored in the binary
>> to be shared across arbitrarily many entries in the line number matrix.
>>
>> This is not currently possible: all modifications to the `line` register
>> are given by relative
>> offsets, and all of these offsets are directly included in the
>> instruction (or implicit in the case
>> of a special opcode).
>>
>> ## Overview
>>
>> Introduce new fields to the line number program header,
>> `indirect_lines_length` (ULEB128) and
>> `indirect_lines` (opaque block of bytes containing ULEB128 values). The
>> `indirect_lines_length`
>> field is the length in bytes of the `indirect_lines` section, rather
>> than the number of elements.
>> Introduce a new standard opcode to the line number program,
>> `DW_LNS_indirect_line`. This opcode
>> takes a single ULEB128 operand, which represents a byte offset into the
>> `indirect_lines` stored in
>> the header. The effect of this instruction is to set the `line` register
>> to the ULEB128 value stored
>> at the given byte offset into `indirect_lines`. Note that
>> `indirect_lines` is not itself validated
>> to be a valid sequence of ULEB128 values; decoding only occurs when
>> `DW_LNS_indirect_line` is used.
>> This allows an incremental compiler to pre-allocate a large amount of
>> padding space in
>> `indirect_lines` to fill in later as needed.
>>
>> Note that an incremental compiler would not necessarily wish to use
>> variable-length integers to
>> represent this information, since certain changes of line numbers could
>> cause a line number which
>> was previously encoded using 1 byte to now require 2. However, since the
>> stored values need not be
>> densely packed, an implementation is free to reserve as much space as is
>> necessary for each entry.
>> For instance, the downstream Zig compiler (which is the original
>> motivator for this proposal) may
>> choose to reserve 4 or 5 bytes for each line number, as line numbers in
>> Zig source files cannot
>> exceed 1<<32. The use of ULEB128 allows the compiler to make an
>> appropriate decision here instead of
>> codifying such a restriction into the DWARF specification.
>>
>> ## Proposed Changes
>>
>> Pages and line numbers are given for the 2024-06-16 working draft of
>> DWARF Version 6, which is the
>> latest draft at the time of writing.
>>
>> 6.2.4 (pg 163; line 27)
>>
>> 21. indirect_lines_length (ULEB128)
>>  The length in bytes of the data stored in the `indirect_lines` field.
>> 22. indirect_lines (block containing ULEB128 entries)
>>  A collection of line numbers, each stored as a ULEB128 integer.
>> These values are referenced by
>>  DW_LNS_indirect_line instructions to modify the state of the line
>> number information state
>>  machine.
>>
>>  The data stored in this field is not checked to be a valid sequence
>> of ULEB128 entries. The
>>  contained data may include padding bytes or otherwise invalid data.
>> As such, it is expected that
>>  bytes of this field be accessed only when a DW_LNS_indirect_line
>> instruction refe

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

[Cary Coutant via Dwarf-discuss]

Agreed. I've added this as Issue 241120.1 and assigned DW_LANG_C23 = 0x3e

https://dwarfstd.org/issues/241120.1.html

-cary


On Wed, Nov 20, 2024 at 10:19 AM David Blaikie via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> +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.
>>
>> -- Forwarded message -
>> From: pogo 59 
>> Date: Wed, Nov 20, 2024 at 12:47 PM
>> Subject: Re: [Dwarf-discuss] defaulting to C23 in GCC
>> To: Mark Wielaard 
>>
>>
>> I think it's reasonable to add codes such as this at least until DWARF v6
>> is published. It's just a list on a web page, right? Like the language
>> codes.
>>
>> On Wed, Nov 20, 2024 at 10:59 AM Mark Wielaard via Dwarf-discuss <
>> dwarf-discuss@lists.dwarfstd.org> wrote:
>>
>>> Hi Jakub,
>>>
>>> On Wed, 2024-11-20 at 16:24 +0100, Jakub Jelinek via Dwarf-discuss
>>> wrote:
>>> > On Wed, Nov 20, 2024 at 03:09:02PM +0100, Alexandra Petlanova Hajkova
>>> via Dwarf-discuss wrote:
>>> > > GCC15 (to be released in April/May2025) will default to C23 instead
>>> of the
>>> > > C17.
>>> > >  There is a new way to describe the language standard version used
>>> proposed
>>> > > for DWARF6 but there is nothing like that for DWARF5 (or earlier).
>>> > > DWARF_LANG_C23
>>> > >  needs to be added to DWARF5.
>>> >
>>> > Why?  I think we don't really want to keep adding new DW_LANG_ codes
>>> > to the DWARF 5 set forever.
>>> > The compiler can emit all of
>>> >   DW_AT_language DW_LANG_C17
>>> >   DW_AT_language_name DW_LNAME_C
>>> >   DW_AT_language_version 202311
>>>
>>> Note that a new DWARF5 languge code for DW_LANG_C_plus_plus_23 was
>>> added: https://dwarfstd.org/issues/240616.1.html and several others
>>> were added just last month https://dwarfstd.org/languages.html
>>>
>>> But you are right we could just adopt the proposed DWARF6
>>> DW_AT_language_name/version attributes, which is more flexible.
>>> Question is if we think they are already "stable".
>>> https://dwarfstd.org/languages-v6.html says "The information on this
>>> page is part of the Draft of DWARF Version 6 and is subject to change."
>>>
>>> Cheers,
>>>
>>> Mark
>>> --
>>> Dwarf-discuss mailing list
>>> Dwarf-discuss@lists.dwarfstd.org
>>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>>>
>> --
>> Dwarf-discuss mailing list
>> Dwarf-discuss@lists.dwarfstd.org
>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Request for Metal language id

[Cary Coutant via Dwarf-discuss]

This is Issue 24.1 . I've
assigned DW_LANG_Metal = 0x3d and DW_LNAME_Metal = 0x002c.

Thanks!

-cary


On Mon, Nov 11, 2024 at 5:53 PM Daniel Sanders via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> Hi,
>
> I would like to request a language id to support the Metal Shading
> Language (
> https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf
> )
>
> Proposed Changes:
> [DWARF 5, Section 3.1.1, pg 62, Table 3.1. Language Names] - Add
>
> DW_LANG_Metal, Metal
>
> [DWARF 5, Section 7.12, pg 230, Table 7.17. Language Encodings] - Add
>
> DW_LANG_Metal, Value to be assigned, 0
>
> [DWARF6 (dwarf6-20241012-1942.pdf), Section 3.1.1, pg 63, Table 3.1.
> Language Names] - Add
>
> DW_LNAME_Metal, Metal, VVMMPP
>
> [DWARF6 (dwarf6-20241012-1942.pdf), Section 7.12, pg 241, Table 7.17.
> Language Encodings] - Add
>
> DW_LNAME_Metal, Value to be assigned, 0
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Missing a useful reference Figure F.2.3 DWARF5 . [Revised.]

[Cary Coutant via Dwarf-discuss]

> Maybe just say that
>
> "For example, some of
> the location list entry encoding
> values in the table(Section 7.7.3 on page 226)
> cannot be used in a .debug_loclists.dwo section."

It does seem like we should say something like that somewhere, and we
do — in Section 2.6 ("The following kinds of location list entries are
defined for use only in non-split DWARF units"). And, similarly for
range lists, in Section 2.17.3.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Missing a useful reference Figure F.2.3 DWARF5 . Reference incorrect.

[Cary Coutant via Dwarf-discuss]

> "The .debug_loclists.dwo section contains the location
> lists referenced by DW_AT_location attributes in the
> .debug_info.dwo section. This section has a similar format
> to the .debug_loclists section in a non-split object,
> but it has some small differences as explained in Section
> 7.7.3 on page 226."
>
> Page 405 line 22.
>
> 7.7.3 has no explanation whatever.
> It is just a list of DW_LLE names, so the
> reference is incorrect.

Ah, that's probably left over from before we adopted the new DW_LLE
encoding for the non-split case. In the original split-DWARF proposal,
the new encoding was only for the .debug_loclists.dwo section; the
.debug_loclists section in a non-split compilation was meant to keep
the old DWARF-4 format. We should just strike that sentence.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] [Proposal] Allow alternate encoding of DW_AT_object_pointer as a variable index instead of DIE reference

[Cary Coutant via Dwarf-discuss]

Thanks! I've added this as Issue 250130.1:

https://dwarfstd.org/issues/250130.1.html

-cary


On Thu, Jan 30, 2025 at 4:01 AM Michael Buch via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> # Allow alternate encoding of DW_AT_object_pointer as a variable index
> instead of DIE reference
>
> ## Background
>
> `DW_AT_object_pointer` is used by LLDB to conveniently determine the
> CV-qualifiers
> and storage class of C++ member functions when reconstructing types from
> DWARF.
> GCC currently emits `DW_AT_object_pointer` on both declaration and
> definition DIEs [1].
> Clang does not emit them on declarations, making the LLDB heuristics
> to find the object
> parameter fragile. We tried attaching `DW_AT_object_pointer` to
> declarations in Clang
> too [2], but that came at the cost of a ~5-10% increase in the
> `.debug_info` section size
> for some users, so we reverted it. This proposal describes an
> alternate encoding of the
> `DW_AT_object_pointer` which allows us to add it to declaration DIEs
> without
> incurring such size overheads.
>
> ## Overview
>
> The idea is to encode the index of the `DW_TAG_formal_parameter` that is
> the
> object parameter instead of a DIE reference. This index could then be of
> form
> `DW_FORM_implicit_const`, so we don't pay the 4 bytes for each reference,
> but instead pay for it once in the abbreviation.
>
> The implementation in Clang for this is currently being discussed in [3].
>
> The DWARF spec currently only mentions `reference` as the attribute class
> of `DW_AT_object_pointer`. So consumers may be surprised by this alternate
> encoding. Hence we thought it'd be good to run this past the committee.
>
> An alternative solution could be a new attribute describing the object
> parameter index (e.g., `DW_AT_object_pointer_index` with a `constant`
> attribute class).
>
> ## Proposed Changes
>
> In chapter "7.5.4 Attribute Encodings", change the "Table 7.5:
> Attribute encodings"
> table as follows:
>
> [ORIGINAL TEXT]
> >>>
> Attribute Name | Value | Classes
> ---
> ...
> DW_AT_object_pointer| 0x64  | reference
> ...
> [NEW TEXT]
> ==
> Attribute Name | Value | Classes
> ---
> ...
> DW_AT_object_pointer| 0x64  | reference, constant
> ...
> <<<
>
> In chapter "5.7.8 Member Function Entries", extend the attribute class
> recommendation
> as follows:
>
> [ORIGINAL TEXT]
> >>>
> If the member function entry describes a non-static member function, then
> that
> entry has a DW_AT_object_pointer attribute whose value is a reference to
> the
> formal parameter entry that corresponds to the object for which the
> function is
> called.
> [NEW TEXT]
> ==
> If the member function entry describes a non-static member function, then
> that
> entry has a DW_AT_object_pointer attribute whose value is a reference to
> the
> formal parameter entry that corresponds to the object for which the
> function is
> called. A producer may also choose to represent it as a constant whose
> value is
> the zero-based index of the formal parameter that corresponds to the object
> parameter.
> <<<
>
> ## References
>
> * [1]: https://godbolt.org/z/3TWjTfWon
> * [2]: https://github.com/llvm/llvm-project/pull/122742
> * [3]: https://github.com/llvm/llvm-project/pull/124790
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

>
> 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 is a (signed) LEB128 relative DIE
> offset - relative to the start of the DIE containing the attribute value?
>
> This would allow for other shortenings of DIEs that are commonly nearby.
>
> I don't have measurements on how much it could decrease DWARF size, but
> could maybe prototype such a thing (bit expensive, because it makes DWARF
> byte size dependent on itself in some ways - and LLVM's DWARF generation
> precomputes DIE offsets, etc, rather than relying on assembler relaxation)
>

Yes, it's worth discussing, but I suspect the downsides you've mentioned
would outweigh any benefits obtained by using an offset rather than an
index. If anything, I'd think the index would be more useful if
you read and internalize the DIE tree. An index would also almost always be
a single byte (and its size would be predictable), while an offset would be
more likely to require 2 bytes.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] DW_IDX_parent semantic

[Cary Coutant via Dwarf-discuss]

Filed as Issue 250131.1.

https://dwarfstd.org/issues/250131.1.html

Thanks!

-cary


On Fri, Jan 31, 2025 at 2:20 PM Cary Coutant  wrote:

> In Section 6.1.1.2, the parent index entry attribute is described as:
>>
>>   Parent debugging information entry, a reference to the index entry for
>>   the parent. This is represented as the offset of the entry relative to
>>   the start of the entry pool.
>>
>> But in Table 6.1, DW_IDX_parent is described as:
>>
>>   Index of name table entry for parent
>>
>> These two seem to contradict each other.  The first one makes more
>> sense, as it points to a specific index entry, making it non-ambiguous.
>> With the second one, pointing to an name table entry, how to you know
>> which of the (possibly multiple) entries associated to that name is the
>> parent?
>>
>> Is is just an honest mistake that should be fixed, or am I missing
>> something?
>>
>
> I'm pretty sure it was meant to be a reference to the index entry, not the
> name table entry. It looks like the mistake in Table 6.1 dates all the way
> back to the first version of the proposal. I'll file this as a new issue
> for the committee to discuss.
>
> -cary
>
>>
>> This caused confusion with the LLVM team here, where it was believed
>> that either meaning was acceptable:
>>
>>
>> https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/16
>>
>> In the end, LLVM implemented the "offset to the index entry" approach.
>>
>> Unfortunately, GDB implemented the "name table index" approach (but Tom
>> Tromey noted that it was a curious choice on the part of DWARF, because
>> of the ambiguousness, I guess he only saw the Table 6.1 definition).
>> However, I believe it should be possible to migrate to the other
>> approach, and differentiate which approach is used using the form, on
>> the reader side.
>>
>> Simon
>> --
>> Dwarf-discuss mailing list
>> Dwarf-discuss@lists.dwarfstd.org
>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>>
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] DW_IDX_parent semantic

[Cary Coutant via Dwarf-discuss]

>
> In Section 6.1.1.2, the parent index entry attribute is described as:
>
>   Parent debugging information entry, a reference to the index entry for
>   the parent. This is represented as the offset of the entry relative to
>   the start of the entry pool.
>
> But in Table 6.1, DW_IDX_parent is described as:
>
>   Index of name table entry for parent
>
> These two seem to contradict each other.  The first one makes more
> sense, as it points to a specific index entry, making it non-ambiguous.
> With the second one, pointing to an name table entry, how to you know
> which of the (possibly multiple) entries associated to that name is the
> parent?
>
> Is is just an honest mistake that should be fixed, or am I missing
> something?
>

I'm pretty sure it was meant to be a reference to the index entry, not the
name table entry. It looks like the mistake in Table 6.1 dates all the way
back to the first version of the proposal. I'll file this as a new issue
for the committee to discuss.

-cary

>
> This caused confusion with the LLVM team here, where it was believed
> that either meaning was acceptable:
>
>
> https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/16
>
> In the end, LLVM implemented the "offset to the index entry" approach.
>
> Unfortunately, GDB implemented the "name table index" approach (but Tom
> Tromey noted that it was a curious choice on the part of DWARF, because
> of the ambiguousness, I guess he only saw the Table 6.1 definition).
> However, I believe it should be possible to migrate to the other
> approach, and differentiate which approach is used using the form, on
> the reader side.
>
> Simon
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Default Lower Bound for Fortran18

[Cary Coutant via Dwarf-discuss]

Yes, this appears to be a typo when Fortran18 was added to the page. I've
noted this error as Issue 241121.1:

https://dwarfstd.org/issues/241121.1.html

I've also added Issue 241121.2 to add a DWARF 5 language code Fortran 23
and assigned DW_LANG_Fortran23 = 0x003f:

https://dwarfstd.org/issues/241121.2.html

We will continue adding new DW_LANG language codes as necessary at least
until DWARF 6 is published, and probably for a while after that. Newly
assigned DW_LANG codes are considered addenda to the spec for DWARF 5, and
should be valid to use with earlier DWARF versions as well.

-cary


On Thu, Nov 21, 2024 at 8:40 AM Jakub Jelinek via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> On Thu, Nov 21, 2024 at 05:22:48PM +0100, Mark Wielaard via Dwarf-discuss
> wrote:
> > The Default Lower Bound for DW_LANG_Fortran18 on
> > https://dwarfstd.org/languages.html is listed as 0.
> > I cannot find a reference for Fortran 2018 changing the default lower
> > bound for arrays from 1 to 0. I am a Fortran noob. But I think this
> > might be a typo and it should really be 1?
>
> 23-007r1.pdf
> (Fortran 2023 draft) says in 8.5.8.2:
> "If no lower bound is specified in an explicit-shape-bounds-spec, all the
> lower bounds are equal to one."
> So yes, it should be 1, and we should have then a language code for
> Fortran 2023 as well.
>
> Although, I'm unsure if compilers really should start using these
> post-DWARF5 DW_LANG_* codes, even if newer versions of consumers are
> adjusted to handle those, if the compiler doesn't have guarantee it will be
> only used with all those newer consumers, using say DW_LANG_C11 or
> DW_LANG_C_plus_plus_14 or DW_LANG_Fortran08 for C23, C++23 or Fortran18
> means it will work even with the older consumers, while switching to the
> new
> ones means trading of some theoretical advantages (what consumers actually
> care about exact C/C++/Fortran version right now) compared to making it
> completely useless with older DWARF 5 compatible consumers (because it will
> be an unknown language for those).
>
> Jakub
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] DW_AT_discr_value improvement

[Cary Coutant via Dwarf-discuss]

Filed as issue 250118.1:

https://dwarfstd.org/issues/250118.1.html

-cary


On Wed, Jan 22, 2025 at 10:45 AM David Blaikie  wrote:

> +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 Mon, Jan 20, 2025 at 4:32 PM Tom Tromey via Dwarf-discuss <
> dwarf-discuss@lists.dwarfstd.org> wrote:
>
>> > "John" == John DelSignore  writes:
>>
>> John> Is the discriminant value always a constant? Perhaps DWARF should
>> say,
>> John> "The value of this attribute is of class constant." Table 2.3
>> defines
>> John> attribute class constant as, "One, two, four, eight or sixteen bytes
>> John> of uninterpreted data, or data encoded in the variable length format
>> John> known as LEB128 (see Section 7.6 on page 221).".
>>
>> Yeah, makes sense to me.
>> What I meant by:
>>
>> >>   Additionally there doesn't seem to be any
>> >> reason to limit the forms that may be used here.
>>
>> ... is that any constant form seems fine.
>>
>> Tom
>> --
>> Dwarf-discuss mailing list
>> Dwarf-discuss@lists.dwarfstd.org
>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>>
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

On Wed, Jan 22, 2025 at 2:54 AM Michael Buch via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> # DW_AT_object_pointer: clarify wording around implicit versus
> explicit object parameters


Filed as Issue 250122.1:

https://dwarfstd.org/issues/250122.1.html

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

> Here is an updated version of the proposal, based on the discussion during 
> the last meeting. Changes from the last revision:
> - fixed typo (DW_AT_location)
> - added table entries in chapter 7
> - improved legibility of example

Thanks! I've updated the issue.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

Adrian, I took the liberty of applying Ron's minor suggested edits for the
non-normative text, and updated the issue.

-cary

On Fri, Mar 14, 2025 at 2:06 PM Ron Brender  wrote:

> Adrian et al,
>
> Re 1: OK, not bad. I would tweak a bit farther:
>  . replace "they are implemented" with "access is implemented"
>  . replace "both" with "programmed constraints, including".
>
> So the results reads:
>
> [Non-normative] *Object-oriented languages like Pascal and Objective-C
> have properties, which are variable- or data member-like entities of units
> or classes. Syntactically, properties can be accessed like variables and
> data members, however,access is implemented by invoking user-defined or
> compiler-generated subprograms, allowing programmed constraints, including
> read-only and write-only semantics.*
>
> Re 4: Good. I might have used "IP" but what you did is OK too.
>
> Ron
>
>
>
> On Fri, Mar 14, 2025 at 1:02 PM Adrian Prantl  wrote:
>
>> Here is my suggestion for (1) and (4).
>> I tried to simplify Ron’s wording a bit. Ron, let me know if you think I
>> went to far :-)
>>
>> -- adrian
>>
>>
>>
>>
>> On Mar 11, 2025, at 2:15 PM, Cary Coutant via Dwarf-discuss <
>> dwarf-discuss@lists.dwarfstd.org> wrote:
>>
>> Thanks, Adrian and Ron. I went ahead and applied the grammatical changes
>> Ron suggested (2, 3, 5), but left the more substantive ones (1, 4) for
>> Adrian to address.
>>
>> -cary
>>
>> On Tue, Mar 11, 2025 at 8:59 AM Ron Brender 
>> wrote:
>>
>>> Mmore suggested changes are attached...
>>>
>>> Ron
>>>
>>>
>>> On Mon, Mar 10, 2025 at 12:46 PM Adrian Prantl via Dwarf-discuss <
>>> dwarf-discuss@lists.dwarfstd.org> wrote:
>>>
>>>> Here is the latest revision:
>>>>
>>>> - Removed Pascal-specific wording from text in 5.19 (field -> data
>>>> member)
>>>> - added updates for Appendix A
>>>> - updated Section 7.32 for type signature computation.
>>>>
>>>> -- adrian
>>>>
>>>> --
>>>> Dwarf-discuss mailing list
>>>> Dwarf-discuss@lists.dwarfstd.org
>>>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>>>>
>>> --
>> Dwarf-discuss mailing list
>> Dwarf-discuss@lists.dwarfstd.org
>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>>
>>
>>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Request to add new constant for Nim language

[Cary Coutant via Dwarf-discuss]

Thanks for providing all the necessary info! I've assigned language codes
DW_LANG_Nim = 0x0045 (for DWARF <= 5)
and DW_LNAME_Nim = 0x002f (for DWARF >= 6).

https://dwarfstd.org/issues/250325.1.html

-cary

On Tue, Mar 25, 2025 at 1:26 PM Jacek Sieka via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> Hi!
>
> As community member and maintainer of
> [`nlvm`](https://github.com/arnetheduck/nlvm), an LLVM-based compiler
> for the [Nim language](https://nim-lang.org/), I'd like to propose
> that a new language constant is added for it in v6!
>
> Our current debugging experience is based on pretending to be C and
> using Itanium-abi-based mangling to piggy-back on C++ demanglers which
> of course isn't optimal as the C++ syntax is foreign to many Nim
> developers and the C syntax lacking many "native" Nim quirks. I'd love
> to get the ball rolling on improving things on the debugging front
> with a view to also extend lldb/gdb and similar tools in the future!
>
> The language is currently at version 2.2.2 - major ABI updates are
> expected to touch the "major" version while even minor releases act as
> feature upgrades, the 1.x series ending at 1.6. Indexing is 0-based by
> default (though customizable for array types).
>
> Thanks and happy to answer any questions,
> Jacek
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Enhancement: Associating allocator call sites with type information

[Cary Coutant via Dwarf-discuss]

>
> # Enhancement: Associating allocator call sites with type information
>

Thanks! This is Issue 250407.1:

https://dwarfstd.org/issues/250407.1.html

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Enhancement: Associating allocator call sites with type information

[Cary Coutant via Dwarf-discuss]

Thanks! Fixed.

-cary


On Mon, Apr 7, 2025 at 5:38 PM Jann Horn  wrote:

> On Tue, Apr 8, 2025 at 2:31 AM Cary Coutant  wrote:
> >>
> >> # Enhancement: Associating allocator call sites with type information
> >
> >
> > Thanks! This is Issue 250407.1:
> >
> > https://dwarfstd.org/issues/250407.1.html
>
> Thanks!
>
> Minor nitpick: This doesn't matter, but it seems like the " available ID>" in my proposal was posted without HTML escaping, so it
> is interpreted as an HTML tag and invisible in the rendered page.
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

Alternatively, what if DW_AT_object_pointer could also take a
locdesc-class with a location description? Then, in cases where 'this' is
not a formal parameter, it could provide a location description in the same
manner as the other captured locals you mentioned (presumably with an
fbreg-based computation).

Whichever way we want to go, it sounds like the DWARF spec should provide
the necessary guidance. This looks like a good start to a proposal—Kyle,
would you like to write one? (See https://dwarfstd.org/comment.html.)

-cary


On Wed, Apr 16, 2025 at 2:11 PM David Blaikie via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

>
>
> 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 to identify the
>> `this` pointer argument of member functions because C++ permits
>> unqualified access to member variables. DWARF 3 introduced the
>> DW_AT_object_pointer attribute for this purpose, and modern versions
>> of clang and gcc emit it. lldb actually uses this attribute when
>> present to find the this pointer argument, falling back to checking to
>> see if the first formal parameter to the function looks "this-like",
>> while gdb appears to use a name lookup at all times. Regardless, these
>> end up being interoperable for normal member functions.
>>
>> lambdas that capture the `this` of a member function present the same
>> need for debuggers, as unqualified accesses within the lambda can also
>> access member variables of `this`. Both clang and gcc desugar lambdas
>> to an anonymous struct type whose members are the captured variables,
>> with an operator() implementation that contains the body of the
>> lambda. They, however, different in their representation of a captured
>> `this` pointer.
>>
>> In clang's case the DWARF for the operator() contains a
>> DW_TAG_formal_parameter for a `this` parameter which is a pointer to
>> the anonymous struct type. That anonymous struct then contains its own
>> `this` member which is the captured `this`. lldb then contains code in
>> GetLambdaValueObject that recognizes this "double this" pattern and
>> deals with it appropriately.
>>
>> In gcc's case the DWARF for the operator() contains a
>> DW_TAG_formal_parameter for a `__closure` parameter which is a pointer
>> to the anonymous struct type. That anonymous struct contains a
>> `__this` member which is the captured `this`. Additionally, gcc emits
>> a DW_TAG_variable inside the operator() named `this` with the
>> appropriate DW_AT_location that traverses the anonymous struct (as it
>> does for all captured variables).
>>
>> In both cases the compilers emit a DW_AT_object_pointer on the
>> operator() pointing to the anonymous struct pointer parameter.
>>
>> This results in neither debugger being able to understand the output
>> of the opposite compiler. gdb cannot understand what clang has emitted
>> because it looks at the `this` parameter (which points to the
>> anonymous struct) and lldb cannot understand what gcc has emitted
>> because it expects the "double this" pattern. This is also annoying
>> for third party debuggers (like the one I maintain) because we need to
>> recognize and explicitly support both patterns.
>>
>> I haven't done any research into why the compilers chose to emit what
>> they do, but it seems to me[0] like things would be better if clang
>> copied gcc's "repeat the captured variables as locals inside
>> operator()" behavior (which would make gdb understand clang binaries)
>> and then both compilers switched their DW_AT_object_pointers to point
>> to the captured `this` if and only if it exists (which would make lldb
>> understand gcc binaries), ignoring the anonymous compiler-generated
>> struct entirely. Then lambdas that capture `this` would look like
>> member functions to debuggers and "just work" without any special
>> lambda-aware code.
>>
>> This would require at least some clarification in the spec since the
>> subprogram's DW_AT_object_pointer would point to a local, not a
>> parameter, and would point to an object of a different type than the
>> DW_TAG_class_type containing the subprogram (or would exist on a
>> subprogram not contained in a class at all if compilers elided the
>> anonymous struct from DWARF entirely).
>>
>> Any thoughts?
>>
>
> As a clang developer, I've some bias for the Clang representation here -
> and lambdas are classes (per the C++ spec) so it still makes sense to me
> that op() is a member function, though, yeah, having its "this" pointer
> given another name since users can't refer to it by that name.
>
> Introducing a bunch of locals that expose the right names/types - seems OK
> to me.
>
> Using object_pointer to refer to a local "this" could have other uses too
> - some languages (I forget which o

Re: [Dwarf-discuss] Enhancement: Dynamic DW_AT_data_bit_offset

[Cary Coutant via Dwarf-discuss]

This is posted as Issue 250501.1:

https://dwarfstd.org/issues/250501.1.html

-cary


On Tue, Apr 29, 2025 at 10:24 AM Tom Tromey via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> > "Simon" == Simon Marchi  writes:
>
> Simon> Just to make sure I understand, can you clarify how
> Simon> DW_AT_data_member_location and DW_AT_bit_offset are used in this
> Simon> case?  In particular, which one is constant and which one is an
> Simon> evaluated expression?
>
> Dynamic DW_AT_data_member_location, static DW_AT_bit_offset:
>
>
>  <5><117a>: Abbrev Number: 17 (DW_TAG_member)
> <117b>   DW_AT_name: (indirect string, offset: 0x1959):
> another_field
> ...
> <1188>   DW_AT_bit_offset  : 6
> <1189>   DW_AT_data_member_location: 6 byte block: 99 3d 1 0 0 22
>  (DW_OP_call4: <0x1193>; DW_OP_plus)
> ...
>  <3><1193>: Abbrev Number: 2 (DW_TAG_dwarf_procedure)
> <1194>   DW_AT_location: 15 byte block: 97 94 1 37 1a 32 1e 23 7
> 38 1b 31 1c 23 3   (DW_OP_push_object_address; DW_OP_deref_size: 1;
> DW_OP_lit7; DW_OP_and; DW_OP_lit2; DW_OP_mul; DW_OP_plus_uconst: 7;
> DW_OP_lit8; DW_OP_div; DW_OP_lit1; DW_OP_minus; DW_OP_plus_uconst: 3)
>
>
> This comes from the description of this gdb patch, which includes a test
> case.  (However, you'd need a patched GCC to get this output.)
>
> https://sourceware.org/pipermail/gdb-patches/2025-April/217289.html
>
> Tom
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] PROPOSAL DW_FORM_implicit_const

[Cary Coutant via Dwarf-discuss]

Thanks. I've added this as Issue 250422.1.

https://dwarfstd.org/issues/250422.1.html

Would we want to delete the following paragraph? Quite possibly yes,
there is little reason to suggest repetition is a good idea.

 >If the actual attribute form is itself `DW_FORM_indirect`,
 >the indirection repeats.  There may be one or more
 >occurrences of `DW_FORM_indirect` in sequence until a
 >`non-DW_FORM_indirect` form is reached. The sequence of
 >`DW_FORM_indirect` forms does not have any effect other than
 >to use up space.

I support removing that paragraph. There is no good reason to support a
chain of indirects, and I think it's just asking for trouble.

-cary


On Wed, Apr 23, 2025 at 1:23 PM David Anderson 
wrote:

> On 4/23/25 11:25, Cary Coutant wrote:
> > David,
> >
> > As part of this, we rearrange
> > the references from
> > `DW_FORM_implicit_const`, `DW_FORM_addrx`, and `DW_FORM_indirect`
> > to be listed in the order
> > `DW_FORM_addrx`, `DW_FORM_implicit_const`, and `DW_FORM_indirect`.
> >
> >
> > `DW_FORM_addrx` is not part of the proposal so
> > we keep it separate (just preceding)
> > `DW_FORM_implicit_const` and `DW_FORM_indirect`.
> >
> >
> > Did you mean DW_FORM_addrx_offset where you wrote DW_FORM_addrx here?
> >
> > -cary
>
> Oops. Yes. DW_FORM_addrx_offset.  New in DWARF6.
> DavidA
>
> --
> Space is to place as eternity is to time.
> -- Joseph Joubert
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

[Cary Coutant via Dwarf-discuss]

>
> The first part of this is straightforward. The DWARF for Base will
> contain a member for the vtable pointer, and that plus knowledge of
> how the ABI lays out vtables allows the debugger to effectively do a
> dynamic_cast to obtain a pointer to the most derived object.
> From there the vtable address is compared against the ELF symbol table
> to find the mangled name of the vtable symbol.
>

This made me do a bit of research...

The artificial member for the vtable pointer appears to be a DWARF
extension requested as far back as 2003 and implemented in 2009:

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11208

But I can't find any relevant discussion on the DWARF mailing lists, until
a question arose about that very member in 2022:

   https://dwarfstd.org/pipermail/dwarf-discuss/2022-February/002127.html

It seems to me that, given the apparent need for this information in the
DWARF info, we should have addressed it in DWARF by now. I suspect the
DWARF committee's position was (or would have been) that the ABI tells you
how to find the vtable so it doesn't need to be explicitly recorded in the
DWARF info. But if both GCC and LLVM have decided it's useful enough (and
there's discussion about that point in the original PR that 11208 spun off
from), then we should discuss it. Otherwise, we risk having different
toolchains adopt different solutions. (GCC and LLVM appear to have avoided
that through careful consideration of what the other project was doing.)
The argument in PR 11208 is that it's /legal/ in DWARF to do this, so no
new DWARF feature was requested.

The request in PR 11208 was for three things:

> 1) I'd like to be able to locate the vtable pointer in the class
>structure so that the debugger knows that the hole in the apparent
>layout is not padding.
>
> 2) I'd like to know the type of the target of the vtable pointer, so
>that if the user asks to see it they see something sane.
>
> 3) I'd like to be able to find a specific virtual functions entry in
>the vtable, however I believe that this information will be best
>expressed as a property of the function, not directly of the class
>or vtable. DWARF3 has the DW_AT_vtable_elem_location attribute for
>precisely this information. gcc should generate that too.
>
>Quoting the DWARF spec again :-
>  An entry for a virtual function also has a
>  DW_AT_vtable_elem_location attribute whose value contains a
>  location description yielding the address of the slot for the
>  function within the virtual function table for the enclosing
>  class. The address of an object of the enclosing type is pushed
>  onto the expression stack before the location description is
>  evaluated.

Point #1 is satisfied with an artificial member whose data_member_location
is the offset of the vtable pointer.

I'm not clear how Point #2 was addressed.

Point #3 was addressed via the vtable_elem_location attribute.

Looking at the DWARF generated by GCC (and I'm guessing LLVM does the
same), I see vtable_elem_location attributes that look like this:

<1b8>   DW_AT_vtable_elem_location: 2 byte block: 10 0 (DW_OP_constu: 0)

This is not correct DWARF! It's supposed to be a location description, and
this is merely a DWARF expression that evaluates to an offset relative to
the vtable pointer. The description of the attribute says that address of
an object of the enclosing type is pushed onto the expression stack, so
there really ought to be a DW_OP_deref to get the vtable pointer on the
stack, followed by the DW_OP_constu and DW_OP_add.

Now if we compare this to DW_AT_data_member_location, we see that one valid
form for that attribute is an integer constant providing the offset of the
data member. But even there, if the attribute has a location expression, it
should compute an actual address, not just deliver the offset.

It would seem an obvious and useful extension to DWARF to allow
DW_AT_vtable_elem_location to take a constant class form that provides the
offset relative to the start of the vtable, so an acceptable form of the
attribute might be:

<1b8>   DW_AT_vtable_elem_location: 0   # (using a constant class form)

There's still the question of what do we do about the form GCC is already
emitting (and has been emitting since 2009)? Make it legal? Let it slide
and ask the compilers to fix it?

Getting back to the original request, do we need an issue to provide an
officially-blessed DWARF way to find the vtable pointer? The current
approach seems rather hacky, especially with respect to attaching a special
meaning to the DW_AT_name attribute. Perhaps a DW_AT_vtable_ptr_location
attribute on the class? And maybe a DW_OP_push_vtable_location operator?


> Then things begin to get hairy, the debugger demangles the mangled
> name that exists in the ELF symbol table, chops off the "vtable for "
> prefix on the demangled name, and searches for the type by name in the
> DWARF. If it finds the type, it adjust

Re: [Dwarf-discuss] PROPOSAL DW_FORM_implicit_const

[Cary Coutant via Dwarf-discuss]

David,

As part of this, we rearrange
> the references from
> `DW_FORM_implicit_const`, `DW_FORM_addrx`, and `DW_FORM_indirect`
> to be listed in the order
> `DW_FORM_addrx`, `DW_FORM_implicit_const`, and `DW_FORM_indirect`.


`DW_FORM_addrx` is not part of the proposal so
> we keep it separate (just preceding)
> `DW_FORM_implicit_const` and `DW_FORM_indirect`.


Did you mean DW_FORM_addrx_offset where you wrote DW_FORM_addrx here?

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

[Cary Coutant via Dwarf-discuss]

>
> Actually, for GCC and LLVM, the location is an *index* into vtable, *not*
> an offset. We have a compiler abstraction that knows how to convert the
> DWARF DW_AT_vtable_elem_location to our internal representation of a
> location, because various compilers generate the DWARF differently and the
> contents of the vtable vary by target architecture. For example, on AIX and
> 64-bit Linux-Power, the vtable slot contains a pointer to a TOC entry,
> which in turn contains the pointer to the function followed by the TOC
> value for the function.
>
Ah, I didn't compile a large enough example to see that it's an index
rather than an offset.

> Here's a simple example for a program compiled with Clang on Linux-x86_64.
>
> The DWARF for a virtual function is:
>
> 0x07aa: DW_TAG_subprogram
>   DW_AT_linkage_name("_ZN1A3gooEv")
>   DW_AT_name("goo")
>   DW_AT_decl_file   ("/.../tx_c++11_virtual.cxx")
>   DW_AT_decl_line   (8)
>   DW_AT_virtuality  (DW_VIRTUALITY_virtual)
>   DW_AT_vtable_elem_location(DW_OP_constu 0x1)
>   DW_AT_declaration (true)
>   DW_AT_external(true)
>   DW_AT_containing_type (0x077d "A")
>
> And here is the internal location we created for that virtual function:
>
> {location {{indirect} {ldc 1} {ldc 8} {mul} {plus}}}
>
Now this is what the DWARF expression is supposed to look like.

It's odd to me that—in response to a bug report that complained that
finding the vtable pointer of an object was too much ABI knowledge for the
debuggers to handle—they implemented a buggy vtable_elem_location that
required even more detailed ABI knowledge!

> When that location is eventually used, the value of the vtable pointer is
> first pushed onto the location evaluation stack, and then the above
> location is resolved. The result is the location of the pointer to the
> function.
>
> On AIX, for GCC, we build a location with an extra indirection through the
> TOC pointer to get to location of the function pointer in the TOC entry
> (which just happens to be at offset 0):
>
> {location {{indirect} {ldc 1} {ldc 8} {mul} {plus} {indirect}}}
>
> So, in practice, handling DW_AT_vtable_elem_location is both highly
> compiler and platform dependent. I guess that's what you should expect with
> a permissive standard.
>
But the standard isn't even permissive here! It's very clear (from DWARF 2
on) that it should be an expression that evaluates to the location of the
vtable entry.

If the implementers had wanted to take advantage of a permissive standard,
they'd have been better advised to use a constant form for the vtable
element index. Such a usage could have easily been standardized after the
fact. (And it would have been more space efficient.)

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Enhancement: Dynamic DW_AT_data_bit_offset

[Cary Coutant via Dwarf-discuss]

>
> One way to fix this would be to lift the "integer constant" restriction
> and allow an expression here.


Yes, that would be a reasonable thing to do for DWARF 6. I'm kind of
surprised we didn't allow an expression for DW_AT_data_bit_offset from the
start, especially given that it was allowed for the old DW_AT_bit_offset.

Anyway, given the permissive nature of DWARF, you could go ahead and use
DW_FORM_exprloc for this attribute in DWARF 4 or 5, as long as compiler and
debugger agree on it. We can work to standardize that in DWARF 6.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] [COMMENT] Other: Language code for Algol 68

[Cary Coutant via Dwarf-discuss]

>
> # Adding a language code for Algol 68
>
> ## Background
>
> There is a GCC front-end for Algol 68 under development [1] and it is
> already generating working programs.  For the moment the front-end is
> using a temporary DWARF language code.
>
> ## Overview
>
> Add an official code DW_LANG_Algol68 that GCC can use.
>
> ## Proposed changes
>
> Add an entry to table 7.17 for DW_LANG_Algol68 with a suitable Value.
>
> [1] https://gcc.gnu.org/wiki/Algol68FrontEnd
>
>
Exciting! What versioning scheme would be appropriate? I know only of the
original 1968 version and the 1974 Revised Report, so I suppose  would
be reasonable. And as I recall, the default lower bound is 1.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] [COMMENT] Other: Language code for Algol 68

[Cary Coutant via Dwarf-discuss]

Thanks!

This is issue 250304.1

.

I've assigned DW_LANG_Algol68 = 0x44 and DW_LNAME_Algol68 = 0x2e.

-cary


On Thu, Mar 6, 2025 at 11:53 PM Jose E. Marchesi  wrote:

>
> >>
> >> # Adding a language code for Algol 68
> >>
> >> ## Background
> >>
> >> There is a GCC front-end for Algol 68 under development [1] and it is
> >> already generating working programs.  For the moment the front-end is
> >> using a temporary DWARF language code.
> >>
> >> ## Overview
> >>
> >> Add an official code DW_LANG_Algol68 that GCC can use.
> >>
> >> ## Proposed changes
> >>
> >> Add an entry to table 7.17 for DW_LANG_Algol68 with a suitable Value.
> >>
> >> [1] https://gcc.gnu.org/wiki/Algol68FrontEnd
> >>
> >>
> > Exciting! What versioning scheme would be appropriate? I know only of the
> > original 1968 version and the 1974 Revised Report, so I suppose 
> would
> > be reasonable.
>
> Yes I think  would be perfect.  We intend to keep GNU Algol 68 as a
> strict superlanguage, as defined in the revised report.
>
> > And as I recall, the default lower bound is 1.
>
> Yes.  Unless revised with AT (or @).
>
> Thanks!
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

Thanks, Adrian and Ron. I went ahead and applied the grammatical changes
Ron suggested (2, 3, 5), but left the more substantive ones (1, 4) for
Adrian to address.

-cary

On Tue, Mar 11, 2025 at 8:59 AM Ron Brender  wrote:

> Mmore suggested changes are attached...
>
> Ron
>
>
> On Mon, Mar 10, 2025 at 12:46 PM Adrian Prantl via Dwarf-discuss <
> dwarf-discuss@lists.dwarfstd.org> wrote:
>
>> Here is the latest revision:
>>
>> - Removed Pascal-specific wording from text in 5.19 (field -> data member)
>> - added updates for Appendix A
>> - updated Section 7.32 for type signature computation.
>>
>> -- adrian
>>
>> --
>> Dwarf-discuss mailing list
>> Dwarf-discuss@lists.dwarfstd.org
>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>>
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Request to add new constant for V Language

[Cary Coutant via Dwarf-discuss]

This is Issue 250220.1:

https://dwarfstd.org/issues/250220.1.html

I've assigned the language codes DW_LNAME_V = 0x2d (for DWARF 6) and
DW_LANG_V = 0x43 (for DWARF 5 and earlier).

-cary


On Fri, Feb 21, 2025 at 7:24 AM Jakub Jabłoński  wrote:

> V is still developing and there is no finalized reference yet. We still
> twaek smaller things, but over all syntax is already quite stable. General
> information about the language can be found at https://vlang.io/ and the
> documentation at https://docs.vlang.io. I hope this is not a problem.
>
> Arrays are 0 based. For versionning we use semantic versioning, so VVMMPP
> schema would fit the best.
>
> Sincerely,
> Jakub Jabłoński
>
>
> On Thursday, February 20, 2025 21:06 CET, Cary Coutant 
> wrote:
>
>
> Thanks, I'll add this. We are still assigning DW_LANG constants, so I'll
> assign one.
>
> Can you provide a reference for the V language?
>
> Please also let me know the default lower bound for arrays (0?) and which
> versioning scheme you'll want to use.
>
> -cary
>
>
> On Thu, Feb 20, 2025 at 4:51 AM Jakub Jabłoński via Dwarf-discuss <
> dwarf-discuss@lists.dwarfstd.org> wrote:
>
>> Dear DWARF-discuss List,
>>
>> I hope this email finds you well.
>>
>> I'm writing on behalf of whole V dev team to propose the addition of a new 
>> constant to the DWARF debugging information standard to better support the V 
>> programming language. V languge currently relies on transpilation to C, but 
>> for better debugging experience we are working currently on direct native 
>> support. Therefore to identify new language I propose adding:
>> DW_LNAME_V 0x002d
>>
>> to be used with DW_AT_language_name attribute.
>>
>> Could you please also advise if it is still necessary to add DW_LANG_V 
>> constant (for DW_AT_language) with version 6 of the standard ?
>> I believe this addition would greatly improve the debugging experience for V 
>> programs and enable better tooling support. I'm happy to discuss this 
>> further and provide any additional information you may need.
>>
>> Thank you for your time and consideration.
>>
>> Sincerely,
>>
>> Jakub Jabłoński
>> --
>> Dwarf-discuss mailing list
>> Dwarf-discuss@lists.dwarfstd.org
>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
>
>
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

Thanks, updated.

-cary

On Mon, Feb 17, 2025 at 10:02 AM Adrian Prantl  wrote:

>
>
> > On Feb 17, 2025, at 10:00 AM, Adrian Prantl  wrote:
> >
> > Hi everyone,
> >
> > Here is the latest update to the property proposal based on the feedback
> I’ve received so far.
> >
> > Martin, can you check that everything in here makes sense from a Pascal
> perspective?
> >
> > Changes include:
> > - moved to a new Section 5.19 since properties can be global
> > - added example for the “stored” keyword
> > - fixed the accessibility override mechanism to use
> DW_TAG_accessibility_declaration
> >
> > -- adrian
>
> I apologize for attaching the wrong Markdown file!
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss