Re: [Dwarf-Discuss] debug_names - what should go in ?

[Paul Robinson via Dwarf-Discuss]

The intent of the index is given pretty plainly in the non-normative text at 
the bottom of p.137; you should be able to look up any unqualified name in the 
index.  If the normative text doesn't accomplish that, we have an opportunity 
to improve the spec. ☺

FWIW here's my take:

Enumerations are a bit unusual in that the enumerators are children of the 
enumeration type, but the enumerator names are not qualified by the type name 
(usually—a C++ enum-class should not put enumerators into the index, I think).  
But you need some rule that excludes enumerations that are not otherwise 
"global" (e.g., they are contained in a class or local to a function).

For imported entities, I'd say if the imported entity would have satisfied the 
criteria for inclusion in the index if it had been "inlined" at the point where 
it was imported, then it ought to be in the index.
--paulr


From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On Behalf 
Of David Blaikie via Dwarf-Discuss
Sent: Tuesday, April 10, 2018 12:30 PM
To: Pavel Labath
Cc: dwarf-discuss@lists.dwarfstd.org
Subject: Re: [Dwarf-Discuss] debug_names - what should go in ?

Yep - sounds like it to me.

I suppose, arguably, one could say that successful name lookups of things in 
the index can be fast, while lookups that fail, or find names not in the index 
may be slow - but that seems unacceptable to me (in many cases "slow" would be 
"prohibitively slow" especially the first time - since it'd amount to the 
non-index case: the consumer having to build its own index from scratch)

Maybe Adrian or Eric can talk to how the Apple indexes worked in these cases.

On Tue, Apr 10, 2018 at 9:24 AM Pavel Labath 
mailto:lab...@google.com>> wrote:
On Tue, 10 Apr 2018 at 16:44, David Blaikie 
mailto:dblai...@gmail.com>> wrote:
I'd say any case where a consumer couldn't actually rely on the table to do 
name resolution would be a bug - or at least something that needs to be 
seriously considered/discussed/figured out how the name table can be used in 
those situations.

Agreed.

This question can be demonstrated on a simple c++ program

namespace namesp1 { int var; }
namespace namesp2 = namesp1; // DW_TAG_imported_declaration

enum enum_type { enumerator }; // DW_TAG_enumeration_type, DW_TAG_enumerator

int main() {
  return namesp2::var + enumerator;
}


Debugging with gdb (without any indexes), the following 4 expressions succeed
1) namesp1::var
2) namesp2::var
3) (enum_type)0
4) enumerator

The question is how should an index-aware debugger find the entities referenced 
by expressions 2 and 4 if they are not present in the index?

They way I see it -- it can't. Which would be a bug in the spec by your 
definition.
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] The .debug_str_offsets section and libdwarf/dwarfdump

[Paul Robinson via Dwarf-Discuss]

+wolfgang who did the string-offsets implementation.
--paulr

> -Original Message-
> From: David Anderson [mailto:dave...@linuxmail.org]
> Sent: Monday, April 16, 2018 5:56 PM
> To: David Blaikie; Robinson, Paul; Pavel Labath
> Cc: dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] The .debug_str_offsets section and
> libdwarf/dwarfdump
> 
> On 04/16/2018 09:01 AM, David Blaikie wrote:
> > Adding a few folks working on Clang's DWARF5 functionality to see if
> > this is a known bug (David Anderson mentioned it may've come from
> > Clang r327823) and/or has been fixed.
> >
> > Perhaps a minimal example that produces this behavior/bug would be
> > useful for David to have (not sure if he wants/needs it if this is
> > already fixed and was never released in an official clang release?
> David?)
> 
> An example .o with this fixed would be great,
> I would put it into libdwarf regression tests.
> 
> Need not be from any official release.
> Need not even be correct :-)
> I don't need the source code producing the example
> nor do I need instructions on how to create the
> object file.
> 
> I accept DWARF (and want  DWARF5) examples,
> whether examples with correct or incorrect DWARF.
> Object files  that provide something new (such
> as DWARF5-only features) or
> interesting in DWARF become part of the publicly available
> libdwarf regression test base.
> 
> David Anderson
> 
> --
> Some mornings it just doesn't seem worth it to gnaw through the leather
> straps.  -- Emo Phillips
> 

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

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

[Paul Robinson 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).

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.

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

Using one of the first two has the advantage that they are defined as
of DWARF v2, so the linker doesn't have to pay attention to the DWARF
version of the line table.  DW_LNS_set_basic_block is probably a tiny
bit more efficient than negate_stmt, as the former writes a flag while
the latter does a read+write.

The requirement to end the padding with an end-sequence does mean that
the padding has to be at least three bytes long, but padding using this
tactic can be any amount larger than that.

The specification says that DW_LNE_end_sequence does create a row in
the table, "whose address is that of the byte after the last target 
machine instruction of the sequence."  In general, this opcode can't 
know where the last instruction is, or how long that instruction is, 
therefore normally it would be preceded by some opcode that sets the 
address register.  That is, end-sequence doesn't modify the address 
register before emitting the row.  In the padding scenario, the address 
would be zero, giving us a zero-length sequence.  Hopefully this would 
not confuse any existing consumers too badly.

What do people think?  I'm happy to write up a short bit for the wiki
Best Practices page.

(I'll probably be embarrassed to find that this was discussed before
and I've forgotten, but it does seems worth a note on the wiki.)
Thanks,
--paulr

___
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

[Paul Robinson via Dwarf-Discuss]

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

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

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

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

Ooh I like that.  Should we officially reserve an opcode for this?

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

That's abusing the LEB format again.  I like the undefined extended
opcode idea best, although to satisfy my own pedantry I'd still follow
it with an end_sequence.

Thanks!
--paulr

___
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

[Paul Robinson via Dwarf-Discuss]

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

Okay, fair.

> >>   // 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 had interpreted this to mean that a non-empty line-number program had 
to end with end_sequence; but you are saying that a line-number program
that creates no rows therefore has no sequences, therefore does not have
to end with end_sequence.  That's why smearing with set_basic_block ops
is fine, you use as many as you need to fill up the hole, and done.

Given that sequences are actually described sequences of target machine 
instructions, not line-number program instructions, that sounds okay.
(And it looks like my whiny consumer won't complain either, for once.)

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

I'll have a go at the LLVM dumper, when I get a chance.

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

I think I will!

Thanks,
--paulr

___
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, leb length

[Paul Robinson via Dwarf-Discuss]

> -Original Message-
> From: David Anderson [mailto:dave...@linuxmail.org]
> Sent: Thursday, April 26, 2018 4:48 PM
> To: Robinson, Paul
> Subject: Re: [Dwarf-Discuss] Line table "no-op" sequence, leb length
> 
> On 04/26/2018 10:04 AM, Paul Robinson via Dwarf-Discuss wrote:
> > 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,

(That was Cary, not me, making the suggestion.)

> 
> Ten bytes is the maximum sane leb length in libdwarf.
> Would that fit the 'reasonable maximum length' criterion?
> 
> If not ten ...what is the reasonable maximum?
> Should the next version of DWARF specify  a maximum length?
> 
> DavidA.

Anyone can propose anything.  Ten covers the maximum 64-bit value.
I could see a non-normative remark in the description of LEB128
being beneficial; not sure we'd want to make it a hard requirement.
--paulr


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

[Dwarf-Discuss] Asm syntax for DWARF 5 line table info

[Paul Robinson via Dwarf-Discuss]

I have been working on adding DWARF 5 support to LLVM, and some of
that support requires some assembler syntax tweaks.  It has been
suggested that I publicize those tweaks outside of the LLVM world, 
and this list seems like the most likely place to find the people 
who would be most interested in agreeing on a common syntax.  I'll
assume people know or can easily look up the DWARF features I'm
talking about.

The two line-table features that require assembler syntax tweaks are:
(a) in the file table, adding the MD5 checksum of the source file;
(b) adding the "root" file explicitly to the file table (aka "file 0").

The LLVM assembler believes that the existing syntax for the DWARF form
of the .file directive is:
.file filenumber [ "directory" ] "path"
where filenumber is a positive number >= 1 to be used by the .loc
directives to identify the source file for instructions.

I propose to add a new optional clause to the .file directive, like so:

.file filenumber [ "directory" ] "path" [ md5 checksum ]

where md5 is a keyword and checksum is the integer checksum,
typically expressed as a hex 128-bit value.

If all .file directives provide an md5 checksum, then the assembler
will put that checksum into the DWARF 5 file table.  (If the 
compiler is compiling a preprocessed file, it won't necessarily be
able to provide an MD5 checksum of the original file. This is much
the same argument against having the assembler compute the MD5
checksum itself; it doesn't know that it's actually the same file.)

As a second tweak, I propose that the filenumber may be 0, in which
case the directive specifies the root file and those parameters are 
used for file entry #0.  If no ".file 0" is seen, then the assembler 
will use file #1 as the zeroth file-table entry (so that file will 
be described twice, using both file #0 and file #1).

This is all implemented in LLVM trunk currently, so there are two
questions to ask:
(1) Has your assembler implemented the necessary features differently?
(2) If not, are you okay with the changes I described above?

Thanks,
--paulr

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

Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info

[Paul Robinson via Dwarf-Discuss]

cc binutils

> -Original Message-
> From: Nick Clifton [mailto:ni...@redhat.com]
> Sent: Friday, June 15, 2018 6:18 AM
> To: Robinson, Paul; dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info
> 
> Hi Paul,
> 
> > I have been working on adding DWARF 5 support to LLVM, and some of
> > that support requires some assembler syntax tweaks.  It has been
> > suggested that I publicize those tweaks outside of the LLVM world,
> > and this list seems like the most likely place to find the people
> > who would be most interested in agreeing on a common syntax.
> 
> I think that it would also be wise to include the binutils project
> (binut...@sourceware.org) as they are responsible for the GNU
> Assembler (gas).
> 
> > I propose to add a new optional clause to the .file directive, like so:
> >
> > .file filenumber [ "directory" ] "path" [ md5 checksum ]
> >
> > where md5 is a keyword and checksum is the integer checksum,
> > typically expressed as a hex 128-bit value.
> >
> > If all .file directives provide an md5 checksum, then the assembler
> > will put that checksum into the DWARF 5 file table.
> 
> If there are discrepancies in the md5 checksums, what should the assembler
> do ?

In LLVM, I have the assembler issue a warning if it sees inconsistent use
of the md5 clause.  It's not an error, because I do see it happen when
the compiler is reading a preprocessed file, and the assembler can't tell
the difference between something the compiler produced and a mistake made
by human coding.

Thanks,
--paulr

> 
> Cheers
>   Nick
> 
> 

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

Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info

[Paul Robinson via Dwarf-Discuss]

> -Original Message-
> From: Nick Clifton [mailto:ni...@redhat.com]
> Sent: Monday, June 18, 2018 10:01 AM
> To: Robinson, Paul; dwarf-discuss@lists.dwarfstd.org
> Cc: binut...@sourceware.org
> Subject: Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info
> 
> Hi Paul,
> 
> >>> I propose to add a new optional clause to the .file directive, like
> so:
> >>>
> >>> .file filenumber [ "directory" ] "path" [ md5 checksum ]
> 
> This suggestion is fine with me.  (And the file 0 enhancement).

Thanks!

> Are you offering to provide an implementation ?

I implemented it in LLVM.  I am not offering to implement it in GNU binutils
as I can't say I know my way around there, or know the current state of
gcc/binutils support for DWARF v5 in general.

> It would help if you could file an enhancement request in the FSF binutils
> bugzilla system, so that we can track any further correspondence on this
> issue.

Sure.  Is that sourceware.org/bugzilla?  It doesn't seem to like the
account I created for gcc.gnu.org/bugzilla a few years ago, but maybe they 
are separate?  Private reply is fine.
Thanks,
--paulr

> 
> Cheers
>   Nick
> 

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

Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info

[Paul Robinson via Dwarf-Discuss]

Filed as bug #23310 at sourceware.org/bugzilla.
--paulr

> -Original Message-
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of Paul Robinson via Dwarf-Discuss
> Sent: Monday, June 18, 2018 1:06 PM
> To: ni...@redhat.com; dwarf-discuss@lists.dwarfstd.org
> Cc: binut...@sourceware.org
> Subject: Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info
> 
> 
> 
> > -Original Message-
> > From: Nick Clifton [mailto:ni...@redhat.com]
> > Sent: Monday, June 18, 2018 10:01 AM
> > To: Robinson, Paul; dwarf-discuss@lists.dwarfstd.org
> > Cc: binut...@sourceware.org
> > Subject: Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info
> >
> > Hi Paul,
> >
> > >>> I propose to add a new optional clause to the .file directive, like
> > so:
> > >>>
> > >>> .file filenumber [ "directory" ] "path" [ md5 checksum ]
> >
> > This suggestion is fine with me.  (And the file 0 enhancement).
> 
> Thanks!
> 
> > Are you offering to provide an implementation ?
> 
> I implemented it in LLVM.  I am not offering to implement it in GNU
> binutils
> as I can't say I know my way around there, or know the current state of
> gcc/binutils support for DWARF v5 in general.
> 
> > It would help if you could file an enhancement request in the FSF
> binutils
> > bugzilla system, so that we can track any further correspondence on this
> > issue.
> 
> Sure.  Is that sourceware.org/bugzilla?  It doesn't seem to like the
> account I created for gcc.gnu.org/bugzilla a few years ago, but maybe they
> are separate?  Private reply is fine.
> Thanks,
> --paulr
> 
> >
> > Cheers
> >   Nick
> >
> 
> ___
> 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

[Dwarf-Discuss] DWARF dumpers should note compressed sections

[Paul Robinson via Dwarf-Discuss]

Recently somebody was poking around looking at compressed DWARF sections,
and observed that some tools (dwarfdump, objdump, readelf) were dumping
them just fine, but without any indication that the original section was
compressed (citing ELF flag SHF_COMPRESSED).  If anybody on this list
happens to be a maintainer of a DWARF dumper :0) they might want to take
a look at reporting this tidbit.

I know that some toolchains prefix a compressed section name with "z"
(e.g., .zdebug_info) but I wasn't aware of the ELF section flag.
--paulr

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

[Dwarf-Discuss] Alternate entry points

[Paul Robinson via Dwarf-Discuss]

On one of the LLVM lists, a question came up about representing alternate
entry points. Fortran and PL/I and probably other languages can do this.

I see DWARF has DW_TAG_entry_point, however the spec is completely silent
on how this entry relates to other entries for the same subprogram.
Should there be one "primary" DW_TAG_subprogram, which then owns the
alternate DW_TAG_entry_point entries?  Or maybe several sibling entries
all with DW_TAG_entry_point, and no primary DW_TAG_subprogram entry?
I don't have a Fortran compiler handy to try this with so I'm curious
what the current state-of-the-practice is (and of course whether this
ought to be spelled out in the spec itself).

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

Re: [Dwarf-Discuss] Alternate entry points

[Paul Robinson via Dwarf-Discuss]

> -Original Message-
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of Paul Robinson via Dwarf-Discuss
> Sent: Tuesday, October 23, 2018 5:40 PM
> To: dwarf-discuss@lists.dwarfstd.org
> Subject: [Dwarf-Discuss] Alternate entry points
> 
> On one of the LLVM lists, a question came up about representing alternate
> entry points. Fortran and PL/I and probably other languages can do this.
> 
> I see DWARF has DW_TAG_entry_point, however the spec is completely silent
> on how this entry relates to other entries for the same subprogram.
> Should there be one "primary" DW_TAG_subprogram, which then owns the
> alternate DW_TAG_entry_point entries?  Or maybe several sibling entries
> all with DW_TAG_entry_point, and no primary DW_TAG_subprogram entry?
> I don't have a Fortran compiler handy to try this with so I'm curious
> what the current state-of-the-practice is (and of course whether this
> ought to be spelled out in the spec itself).

I dug up gfortran 5.4, which does not emit DW_TAG_entry_point with my
simple example program.  Does anybody actually use it?
--paulr

> 
> 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] Alternate entry points

[Paul Robinson via Dwarf-Discuss]

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, October 24, 2018 6:16 AM
> To: Rafik Zurob
> Cc: Robinson, Paul; dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] Alternate entry points
> 
> On Wed, Oct 24, 2018 at 01:00:26AM -0400, Rafik Zurob via Dwarf-Discuss
> wrote:
> > > I dug up gfortran 5.4, which does not emit DW_TAG_entry_point with my
> > > simple example program.  Does anybody actually use it?
> >
> > IBM XL Fortran generates it.
> >
> > $ cat entry.f
> > subroutine foo(a)
> >   integer a
> >   real b
> >
> >   a = 5
> >   return
> > entry bar(b)
> >   b = 3.0
> >   return
> > end subroutine
> > $
> >
> > Gets the following DWARF:
> 
> That is kind of weird, because foo only has dummy argument a
> and entry bar only has b, there is nothing that tells the debug info
> consumer that the subprogram doesn't have (a, b) arguments.
> 
> >  <1><42>: Abbrev Number: 2 (DW_TAG_base_type)
> > <43>   DW_AT_name: INTEGER
> > <4b>   DW_AT_byte_size   : 4
> > <4c>   DW_AT_encoding: 5(signed)
> >  <1><51>: Abbrev Number: 2 (DW_TAG_base_type)
> > <52>   DW_AT_name: REAL
> > <57>   DW_AT_byte_size   : 4
> > <58>   DW_AT_encoding: 4(float)
> >  <1><59>: Abbrev Number: 4 (DW_TAG_subprogram)
> > <5a>   DW_AT_name: foo
> > <5e>   DW_AT_low_pc  : 0x0
> > <66>   DW_AT_high_pc : 128
> > <67>   DW_AT_decl_file   : 1
> > <68>   DW_AT_decl_line   : 1
> > <69>   DW_AT_external: 1
> > <6a>   DW_AT_frame_base  : 0x0 (location list)
> >  <2><72>: Abbrev Number: 5 (DW_TAG_formal_parameter)
> > <73>   DW_AT_location: 3 byte block: 91 20 6(DW_OP_fbreg:
> 32;
> > DW_OP_deref)
> > <77>   DW_AT_name: a
> > <79>   DW_AT_type: 0x42
> >  <2><81>: Abbrev Number: 5 (DW_TAG_formal_parameter)
> > <82>   DW_AT_location: 3 byte block: 91 28 6(DW_OP_fbreg:
> 40;
> > DW_OP_deref)
> > <86>   DW_AT_name: b
> > <88>   DW_AT_type: 0x51
> >  <2><90>: Abbrev Number: 6 (DW_TAG_entry_point)
> > <91>   DW_AT_name: bar
> > <95>   DW_AT_low_pc  : 0x28
> > <9d>   DW_AT_decl_file   : 1
> > <9e>   DW_AT_decl_line   : 7
> > <9f>   DW_AT_frame_base  : 1 byte block: 6e (DW_OP_reg30
> > (r30))

If the entry for 'bar' has a formal_parameter child describing 'b'
then this is behaving according to my intuition.
Thanks,
--paulr

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

[Dwarf-Discuss] implicit_value vs stack_value

[Paul Robinson via Dwarf-Discuss]

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

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

[Paul Robinson via Dwarf-Discuss]

(re-sending because outlook omitted the group address)

> -Original Message-
> From: Dwarf-Discuss  On Behalf
> Of Jakub Jelinek via Dwarf-Discuss
> Sent: Tuesday, March 9, 2021 10:16 AM
> To: Andrew Cagney 
> Cc: DWARF Discussion 
> Subject: Re: [Dwarf-Discuss] compilers generating ABI non-compliant
> function calls?
> 
> On Tue, Mar 09, 2021 at 10:05:04AM -0500, Andrew Cagney via Dwarf-Discuss
> wrote:
> > Is anyone aware of a compiler doing this (I figure with LTO there's a
> > strong incentive)?  And if so, how is this described to the debugger.
> > The ABI / calling-convention is no longer on hand for filling in the
> > blanks.
> 
> Sure, GCC does that.  On many architectures, IPA-RA might keep data
> live across a function call even in registers that are per the ABI
> officially call clobbered (if it can prove the particular callee does not
> clobber it).  This isn't expressed in DWARF I believe.


DWARF doesn't describe clobbering or non-clobbering; it describes where
values live.  If something gets clobbered by a call, the location list
should reflect that the location changes (or doesn't exist) as of the
instruction after the call; if it doesn't get clobbered, the location
range should correctly span the call instruction.  The debugger does not
need to know the ABI in order to trust that location lists are correct.
The producer is responsible for emitting correct location lists that
don't depend on ABI knowledge by the consumer.

AFAIK the main reason to annotate a subprogram with a calling convention
is so that a debugger can manufacture a call correctly, in response to a
user command.

It might also be necessary to identify the location of the return value,
as someone else mentioned.
--paulr

> 
> On x86, GCC can use different register calling conventions for local
> functions (basically automatic regparm and/or sseregparm calling
> conventions
> when possible).  I think this is reflected in the debug info, the
> DW_TAG_formal_parameter locations should match those.
> 
>   Jakub
> 
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> https://urldefense.com/v3/__http://lists.dwarfstd.org/listinfo.cgi/dwarf-
> discuss-
> dwarfstd.org__;!!JmoZiZGBv3RvKRSx!saJXjJCyJzGPm7PNYMIYGGdh4Ox2WiUfnoR9uFea
> -PrVPbcUNCuNYk9zgwlQJrcZ9Q$
___
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

[Paul Robinson via Dwarf-Discuss]

Hopefully not to side-track things too much... maybe wants its own
thread, if there's more to debate here.

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

Did you want to file an issue to improve how .debug_aranges works?

Complaining that it duplicates CU ranges is missing the point, though;
it's an index, like .debug_names, of course it duplicates other info.
If you want to suggest an improved index, like we did with .debug_names,
that would be great too.
--paulr

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

Re: [Dwarf-Discuss] debug_aranges use and overhead

[Paul Robinson via Dwarf-Discuss]

Tom Russell could perhaps speak to this better, but my understanding is that 
our debugger guys like having .debug_aranges, because parsing the CU DIE does 
take that extra effort.  I am unfamiliar with their code so I have to take 
their word on it.  But I can certainly imagine that probing hundreds to 
thousands of CUs in order to collect range information with lengthy range lists 
would be more expensive than running through a comparatively compact 
.debug_aranges list.  If Tom tells me I’m wrong, well, wouldn’t be the first 
time.

One thing we have encountered (see issue 210113.1) is that when we’ve done 
dead-stripping, .debug_aranges entries (one per function, typically, because 
-ffunction-sections) can end up pointing to nothing.  In our proprietary linker 
I believe we compress/rewrite .debug_aranges to minimize the number of entries, 
which by coincidence ends up producing a conforming aranges list; LLD doesn’t 
do that, which means it produces a non-conforming list (with zero-length 
entries), hence the issue.

I’ll have to think about what a “modern” .debug_aranges might want to look like.
Thanks,
--paulr

From: David Blaikie 
Sent: Thursday, March 11, 2021 3:48 PM
To: Robinson, Paul 
Cc: Cary Coutant ; DWARF Discuss 

Subject: debug_aranges use and overhead

On Thu, Mar 11, 2021 at 5:48 AM 
mailto:paul.robin...@sony.com>> wrote:
Hopefully not to side-track things too much... maybe wants its own
thread, if there's more to debate here.

Yeah, how about we spin it off into another thread (done here)

>> For the case you suggested where it would be useful to keep the range
>> 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).

Did you want to file an issue to improve how .debug_aranges works?

I don't currently understand the value it provides, and I at least don't have a 
use case for it, so I'm not sure I'd be the best person to advocate/drive that 
work.
Complaining that it duplicates CU ranges is missing the point, though;
it's an index, like .debug_names, of course it duplicates other info.
If you want to suggest an improved index, like we did with .debug_names,
that would be great too.

.debug_names is quite different though - it collects information from across 
the DIE tree - information that is expensive to otherwise gather (walking the 
whole DIE tree).

.debug_aranges is not like that for most producers (producers that do include 
the address ranges on the CU DIE) - the data is readily available immediately 
on the CU. That does involve reading some of .debug_abbrev, and interpreting a 
handful of attributes - but at least for the use cases I'm aware of, that 
overhead isn't worth the size increase.

Do you have numbers on the benefits of .debug_aranges compared to parsing the 
ranges from CU DIEs?

(one possible issue: the CU doesn't /have/ to contain low/high/ranges if its 
children DIEs contain addresses - having that as a guarantee, or some preferred 
way of encoding zero length (high/low of 0 would be acceptable, I guess) would 
be nice & make it cheap to skip over CUs that don't have any address ranges)

Roughly, a modern debug_aranges to me would look something like:







So it could fully re-use the rnglist encoding. If this was going to be as 
compact as possible, it'd need to be configurable which encodings it uses - 
ranges V high/low, addrx V addr - at which point it'd probably look like a 
small DIE with an inline abbrev (similar to the way DWARFv5 encodes the file 
and directory entries now, and how debug_names is self-describing) - at which 
point it looks to me a lot like parsing the CU DIEs.

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

Re: [Dwarf-Discuss] debug_aranges use and overhead

[Paul Robinson via Dwarf-Discuss]

Yeah, we talked some last year about formalizing this more into the -1 
tombstone - I thought maybe Paul had proposed that for standardization, though 
at a glance I don't see the proposal. It's probably somewhere there.

200609.1 Reserve an address value for “not present”
--paulr

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

[Dwarf-Discuss] DWARF v5 and "file 0"

[Paul Robinson via Dwarf-Discuss]

Tom Russell asked me about this, and I think it's a bug in the
v5 specification.

In v5, the line-table header's directory table added an entry for
directory 0.  Previous versions had directory 0 mean the current
compilation directory, i.e. DW_AT_comp_dir from the compile unit DIE.

The file table also added an entry for file 0, claiming that it
similarly used to mean the primary compilation file.  I can't find
any evidence that was actually true, though; the default value for
the line-number program's "file" register was (and still is) 1, not
0, and in fact section 2.14 says that DW_AT_decl_file = 0 means
there is no source file (analogous to line 0 meaning no specific
source line).

If DW_AT_decl_file = 0 means "no source file" then the file table
pretty much has to have two entries for the primary source file, 
entry 0 to satisfy the line-table specification and another non-zero
entry to satisfy the DW_AT_decl_file requirements.  That's wasteful.

Am I missing something?  Happy to be wrong here, but it helps
explain why it has been such a bear to get file 0 working properly
in LLVM.

If I'm not wrong I will file an issue to get this fixed in DWARF v6.
Thanks,
--paulr

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

Re: [Dwarf-Discuss] DWARF v5 and "file 0"

[Paul Robinson via Dwarf-Discuss]

> it sounds like the general consensus is that:
> 
> * In DWARF 5, file name entries are zero-indexed.
> * DW_AT_decl_file of 0 means the first file name entry (index 0, which
>   happens to be the same as DW_AT_name of the unit). It does NOT mean an
>   unspecified file; that was an oversight in the specification.
> 
> Is that correct?

I believe we are coming to that conclusion.  It's certainly how Clang
is implementing this feature.  The DWARF committee hasn't made any
decision about it yet, but it's probably safe to go that direction.
--paulr

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

[Dwarf-Discuss] PSA: New LLVM vendor tag DW_TAG_LLVM_annotation

[Paul Robinson via Dwarf-Discuss]

In the interest of alerting others who maintain lists of 
vendor-defined tags, attributes, etc.:

LLVM recently added DW_TAG_LLVM_annotation (0x6000).
This is a generic way to add an arbitrary name/value pair to
any existing DIE; its use within LLVM is to propagate certain
source attributes into the DWARF.  There's a fairly specific
use-case in one environment, but as the tag itself has no
particular semantics, it might be useful more widely.

If anyone is already using 0x6000 as a vendor tag, it will be
easy for us to change this to another value, if we learn about
it fairly soon.

Thanks!
--paulr

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

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

[Paul Robinson via Dwarf-Discuss]

According to https://en.cppreference.com/w/cpp/language/function the 
cv-qualifier is allowed only on non-static member functions, which are exactly 
the ones that have an implicit this-pointer parameter.
cv
-
const/volatile qualification, only allowed in non-static member function 
declarations
Are cv-qualified free functions or static member functions a GCC extension?  If 
so, then doing what GCC does seems like exactly the right thing to do.  It 
falls within the “permissive” nature of DWARF to do that.  I don’t know that 
the DWARF standard should say anything special about it, though.
--paulr

From: Dwarf-Discuss  On Behalf Of 
David Blaikie via Dwarf-Discuss
Sent: Tuesday, October 5, 2021 3:12 PM
To: DWARF Discuss 
Subject: [Dwarf-Discuss] Inconsistency of C++ member function qualifiers

C++ member functions can be qualified in a number of ways - classic CV (const 
and volatile) qualifiers, and since C++11, lvalue (&) and rvalue (&&) reference 
qualifiers. Details here: 
https://en.cppreference.com/w/cpp/language/member_functions

A note on 5.10, page 127 says:

"C++ const-volatile qualifiers are encoded as part of the type of the 
“this”-pointer. C++11 reference and rvalue-reference qualifiers are encoded 
using the DW_AT_reference and DW_AT_rvalue_reference attributes, respectively. 
See also Section 5.7.8 on page 120."

Though this appears to be inadequate, because C++ allows these qualifiers on 
any function type - even one without a first parameter necessary to carry the 
const/volatile qualifiers.

eg:
template
struct t1 { };
t1 v1;

GCC implements this type by using DW_TAG_const_type around a 
DW_TAG_subroutine_type. I've implemented the same behavior in Clang recently.

For actual member functions (eg: void (some_type::*)() const) both Clang and 
GCC put the const type on the artificial first parameter rather than by 
wrapping the type in DW_TAG_const_type.


Does this seem acceptable, should we do something different to unify the 
representation between these two cases? Should we add some more non-normative 
text in 5.10/p127?

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

Re: [Dwarf-Discuss] Multiple floating point types with the same size but different encodings

[Paul Robinson via Dwarf-Discuss]

+ John Reagan who can (I hope) speak to the choice of using different
ATE codes for distinguishing VAX/IEEE floats in OpenVMS.
--paulor

> -Original Message-
> From: Dwarf-Discuss  On Behalf
> Of Jakub Jelinek via Dwarf-Discuss
> Sent: Monday, January 24, 2022 5:17 PM
> To: Jason Merrill 
> Cc: DWARF Discuss 
> Subject: Re: [Dwarf-Discuss] Multiple floating point types with the same
> size but different encodings
> 
> On Mon, Jan 24, 2022 at 04:52:38PM -0500, Jason Merrill wrote:
> > DW_ATE seems natural, since that's how we express the encoding of a base
> > type.  OTOH, using DW_AT_precision would parallel DW_AT_digit_count for
> > fixed-point encodings.  My concern is that it would be possible to have
> > multiple alternative encodings with the same precision, but perhaps
> that's
> > not sufficiently likely?
> 
> Guess advantage of a special DW_ATE_* for it is that it is smaller,
> DW_AT_encoding has to be specified either way, while we have
> DW_FORM_implicit_const, that will take something at least in
> .debug_abbrev.
> The types we see used together right now (i.e. this double double vs.
> quad IEEE or float16 vs. bfloat16) do differ in precisions.
> There are some differences in some cases even with the same precision,
> e.g. in NaNs (mips vs. rest), but those don't appear together, or the
> VAX floats (but I think on a VAX one will see only those 3 floats there
> and they have different precisions too (24, 53 and 56)).
> 
> The special DW_ATE_* values would need to be in the user range though,
> while DW_AT_precision could be something explained in DWARF6.
> 
>   Jakub

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

Re: [Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings

[Paul Robinson via Dwarf-Discuss]

John Reagan tells me his message didn't go to the list,
but Jakub quotes it in his reply.  My comments below.

> -Original Message-
> From: Jakub Jelinek 
> Sent: Tuesday, January 25, 2022 7:10 AM
> To: John Reagan 
> Cc: Robinson, Paul ; ja...@redhat.com; dwarf-
> disc...@lists.dwarfstd.org
> Subject: Re: [EXTERNAL] - RE: [Dwarf-Discuss] Multiple floating point
> types with the same size but different encodings
> 
> On Mon, Jan 24, 2022 at 09:43:07PM -0500, John Reagan wrote:
> > Yes, on OpenVMS we have 2 32-bit floats (VAX f_float, IEEE s_float), 3
> > 64-bit floats (VAX d_float, VAX g_float, IEEE t_float), and 1 128-bit
> > float (IEEE x_float).  We had a 2nd 128-bit float back on the VAX but we
> > don't support that anymore.
> >
> > Our current encoding on OpenVMS Itanium:
> >
> > DW_ATE_Float: s_float (size 4), t_float (byte size 8), x_float (byte
> > size 16)
> >
> > DW_ATE_complex_float: s_float complex, t_float complex, x_float complex
> >
> > DW_ATE_HP_VAX_float [0x88]: f_float (byte size 4), g_float (byte size 8)
> >
> > DW_ATE_HP_VAX_float_d [0x89]: d_float (byte size 8)
> >
> > DW_ATE_VAX_complex_float [0x8f]: f_float complex, g_float complex
> >
> > DW_ATE_VAX_complex_float [0x90]: d_float complex
> >
> > For choice, I'd guess that Ron might have more history as the comments
> > on the code also say that HP-UX and NSK used the same codes too.  So I
> > don't know if OpenVMS was the first user or if OpenVMS inherited it.

I'd guess that HP-UX got there first, and the VAX-specific ones were added
for OpenVMS later.  NSK had a legacy floating-point format but I don't recall
how we described it.

> 
> If s_float and f_float or t_float and g_float coexist on the same platform
> in the same ABI, I'm afraid DW_AT_precision to distinguish between them,

Did you mean, DW_AT_precision isn't enough to distinguish between them?

> IEEE single has 24-bit significand precision (1 bit implied) and
> it seems s_float does too, and similarly IEEE double has 53-bit precision
> (1 bit implied) and it seems g_gloat does too (d_float has 56-bit
> precision).
> So we'd need also exponent bias (or minimum or maximum exponent)
> to differentiate between them.
> 
>   Jakub

It sounds like ATE codes would be better all around.  We could have a
pile of attributes that parameterize all the things, but that seems
overly general.
--paulr

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

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

[Paul Robinson via Dwarf-discuss]

Also, fixed-size DIEs are much easier when quickly scanning for something;
you can derive the size of the DIE from the abbrev without having to look
at the DIE content. When you have variable-size values such as LEB128 then
you need to parse the values in order to determine where the next DIE
starts.
(Greg Clayton [LLDB] in particular has expressed a strong preference for
fixed-size values for this reason.)
--paulr

On Mon, Feb 3, 2025 at 1:09 AM Cary Coutant  wrote:

> 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