From mjw@redhat.com  Thu Dec  1 01:24:24 2016
From: mjw@redhat.com (Mark Wielaard)
Date: Thu, 01 Dec 2016 02:24:24 +0100
Subject: [Dwarf-Discuss] Some DWARFv5 draft feedback
Message-ID: <1480555464.3728.214.camel@redhat.com>


I have been working on elfutils DWARFv5 support based on what GCC7
implements and the current public draft. I haven't had time to implement
everything. But since the public comment period was kept short I thought
it would be nice to at least document some of the things that I stumbled
over. Hopefully they help to understand why I made some of the choices
when reviewing the patches on the elfutils mjw/DWARF5 branch.

Some of these things seem simple to fix/clarify and I will also submit
Issues for them to dwarfstd.org so they don't get forgotten. Others are
just observations that I struggled with. Which might just need
coordination between producers and consumers. Hope the notes are also
useful for writing other DWARFv5 consumers.

BTW. It would be handy if there were sources for the spec so one can
create patches for simple typos. Also it is somewhat opaque how Issues
are handled. Could they and any comments from the committee be sent to
the mailinglist to make tracking changes to the draft easier.

New Language Encodings. The list still has DW_LANG_C_plus_plus_03 which
was discussed some time ago on the dwarf-discuss list. Since c++03
doesn't introduce any language changes it isn't clear what this
signifies. The original submitter also agreed it wasn't necessary. On
the other hand there is no DW_LANG_C_plus_plus_17, which seems
appropriate and necessary given that final DWARFv5 will probably come
out in 2017 as does GCC7 with C++17 language support.

Handling language specific DIE/Attribute properties in partial units.
This seems hard to handle in the abstract. I wonder if there is some
guidance for producers on what kind of things can be moved into a
partial unit to make things easier for consumers. For example the size
of variable or data structure. e.g. subrange types might omit the
DW_AT_lower_bound attribute in which case the CU language context
determines the lower bound. (0 for C, 1 for Fortran, etc.). What if e.g.
DW_TAG_subrange_type is placed in a partial unit? Then it seems good if
the partial unit DIE has a language attribute. In general it would be
good if the partial unit DIE had a language attribute so the context is
clear for a consumer/library that might need provide language specific
properties for a DIE (given it might be unclear or hard to get at all
the (indirect) imports of the partial unit (and what if some of them
have different language attributes?). Alternatively a producer placing a
DIE into a partial unit might have to add any any attributes, like the
lower bound, that might be implicit if the unit DIE had a language
attribute.

New FORMs. DW_FORM_ref_sup doesn't describe how the offset is
represented. Currently the assumption in elfutils is that it is 4 or 8
bytes depending on whether the containing unit is 32bit or 64bit DWARF.
This would be consistent with DW_FORM_strp_sup. The consequence is that
if the supplemental file has really big data sections you need a 64bit
DWARF unit to reference everything in it. There is no description of the
representation of DW_FORM_line_strp, but DW_FORM_strp is mentioned
twice. I assumed the second should just be DW_FORM_line_strp.
Classifying DW_FORM_data16 as a constant value is slightly confusing.
Having to handle a 128bit value everywhere a constant value class is
allowed is somewhat inconvenient. And such values really only make sense
given a specific data representation/type. As given it isn't immediately
clear in which context one might have to byte-swap for different
endianess (the fact that it also used to represent the MD5 in the line
table confused me a bit, wrongly assuming it meant that I might need to
byte-swap because it was a constant value representation - it shouldn't
of course, it really is a hash represented by a block of bytes). For
these reasons in elfutils we currently handle it as (constant size)
block class (which is what I hear is also what gdb does). In practice it
seems to only impact DW_AT_const_value for which consumers already had
to handle blocks. Using it for other attributes doesn't really seem to
make sense. Suggest to rename to DW_FORM_data16_block and put it in the
block class instead of the constant class. The new DW_FORM_implict_const
did eventually work out well, but there were surprisingly many places
that assumed abbrevs were simple and didn't use much/any abstraction.
The existing DW_FORM_indirect doesn't really seem handled very well,
which would break most of these place too.

Unit headers. Having extra padding fields for all unit types seems a bit
wasteful. Also there is not enough information for a consumer to know
whether it can handle anything from a unit which unit type is unknown.
Which, if any, fields following the unit_type is valid? Or is just the
initial unit_length valid and is the only valid operation skipping the
whole unit? Having a place to store a unique identifier and a reference
to a primary/sub DIE inside the unit is nice and could be made more
generic by turning the unit_type field into a bit/flag field.
One flag to indicate it is a type unit, one for partial unit, one for
skeleton unit and for split unit. Some combinations don't make sense
currently, but might in the future. Or keep the current DW_UT values
(1..6) as they are now. But limit the extensions to 15. Then use the
remaining 4 bits as flags to indicate whether a unit header contains
extra fields. You can define 2 already. One if the header contains an 8
byte ID field. And one if the header contains an DIE offset field (4 or
8 bytes). That basically gives you 16 values for describing the type and
16 for describing the header fields. But you could shift them a bit if
you think it is more important to have flexibility in unit types or
describing header fields/size.

Enumeration types. It is allowed to have a DW_AT_byte_size on a
DW_TAG_enumeration_type, but not DW_AT_encoding. To describe both size
and encoding one needs to use a DW_AT_type pointing to a base type that
represents the "underlying type". For languages where enumerations don't
have an underlying type, or for strongly typed enums it is easier to
attach the encoding directly than adding and indirection to a base type.
Add DW_AT_encoding to the attribute list for DW_TAG_enumeration_type.

Macro Information Header. The macro information entries in the
opcode_operands_table may be described in the table. But some cannot be
described because some forms are not in the list of allowed forms. In
particular DW_FORM_strp_sup is missing so DW_MACRO_define_sup and
DW_MACRO_undef_sup cannot be described. And DW_FORM_ref_sup is missing,
making it impossible to describe DW_MACRO_import_sup. Which makes the
code that checks for allowed forms slightly inconvenient (it should
reject these MACRO descriptions if those forms are used in the table,
but not if they are defined implicitly). Also DW_FORM_line_strp isn't
allowed. But it might be beneficial for describing files referenced by
macros.




From todd.allen@ccur.com  Thu Dec  1 12:59:50 2016
From: todd.allen@ccur.com (Todd Allen)
Date: Thu, 1 Dec 2016 05:59:50 -0700
Subject: [Dwarf-Discuss] Some DWARFv5 draft feedback
In-Reply-To: <1480555464.3728.214.camel@redhat.com>
References: <1480555464.3728.214.camel@redhat.com>
Message-ID: <20161201125950.GA20117@toad.ccur.com>

> 
> Enumeration types. It is allowed to have a DW_AT_byte_size on a
> DW_TAG_enumeration_type, but not DW_AT_encoding. To describe both size
> and encoding one needs to use a DW_AT_type pointing to a base type that
> represents the "underlying type". For languages where enumerations don't
> have an underlying type, or for strongly typed enums it is easier to
> attach the encoding directly than adding and indirection to a base type.
> Add DW_AT_encoding to the attribute list for DW_TAG_enumeration_type.
> 

FWIW, our Ada compiler always placed DW_AT_encoding attributes directly on
DW_TAG_enumeration_type to indicate the underlying signedness.  Ada never was
truly supported, so we just viewed it as part of the Ada support we'd defined.

-- 
Todd Allen
Concurrent Computer Corporation


From paul.robinson@sony.com  Thu Dec  1 13:52:47 2016
From: paul.robinson@sony.com (Robinson, Paul)
Date: Thu, 1 Dec 2016 13:52:47 +0000
Subject: [Dwarf-Discuss] Some DWARFv5 draft feedback
In-Reply-To: <1480555464.3728.214.camel@redhat.com>
References: <1480555464.3728.214.camel@redhat.com>
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEAF4950529@USCULXMSG08.am.sony.com>

Thanks for reporting this stuff!  I see a few things you found have
already been reported, but please make sure to file issues for the
rest so we can clean up as much as we can.

> New FORMs. DW_FORM_ref_sup doesn't describe how the offset is
> represented. Currently the assumption in elfutils is that it is 4 or 8
> bytes depending on whether the containing unit is 32bit or 64bit DWARF.
> This would be consistent with DW_FORM_strp_sup. The consequence is that
> if the supplemental file has really big data sections you need a 64bit
> DWARF unit to reference everything in it.

Already filed as issue 161114.1.
http://dwarfstd.org/ShowIssue.php?issue=161114.1

> There is no description of the
> representation of DW_FORM_line_strp, but DW_FORM_strp is mentioned
> twice. I assumed the second should just be DW_FORM_line_strp.

Already reported to the editor as a typo, not filed as an issue.

> Macro Information Header. The macro information entries in the
> opcode_operands_table may be described in the table. But some cannot be
> described because some forms are not in the list of allowed forms. In
> particular DW_FORM_strp_sup is missing so DW_MACRO_define_sup and
> DW_MACRO_undef_sup cannot be described. And DW_FORM_ref_sup is missing,
> making it impossible to describe DW_MACRO_import_sup. Which makes the
> code that checks for allowed forms slightly inconvenient (it should
> reject these MACRO descriptions if those forms are used in the table,
> but not if they are defined implicitly). Also DW_FORM_line_strp isn't
> allowed. But it might be beneficial for describing files referenced by
> macros.

Good catch.  I see there is issue 161031.3 which has to do with allowed 
forms in the line table, but I'm not seeing one for the macro section.

Thanks,
--paulr



From jakub@redhat.com  Thu Dec  1 14:04:31 2016
From: jakub@redhat.com (Jakub Jelinek)
Date: Thu, 1 Dec 2016 15:04:31 +0100
Subject: [Dwarf-Discuss] Some DWARFv5 draft feedback
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEAF4950529@USCULXMSG08.am.sony.com>
References: <1480555464.3728.214.camel@redhat.com>
	<E3B07FDB86BFF041819DC057DEED8FEAF4950529@USCULXMSG08.am.sony.com>
Message-ID: <20161201140431.GL3541@tucnak.redhat.com>

On Thu, Dec 01, 2016 at 01:52:47PM +0000, Robinson, Paul wrote:
> Thanks for reporting this stuff!  I see a few things you found have
> already been reported, but please make sure to file issues for the
> rest so we can clean up as much as we can.
> 
> > New FORMs. DW_FORM_ref_sup doesn't describe how the offset is
> > represented. Currently the assumption in elfutils is that it is 4 or 8
> > bytes depending on whether the containing unit is 32bit or 64bit DWARF.
> > This would be consistent with DW_FORM_strp_sup. The consequence is that
> > if the supplemental file has really big data sections you need a 64bit
> > DWARF unit to reference everything in it.
> 
> Already filed as issue 161114.1.
> http://dwarfstd.org/ShowIssue.php?issue=161114.1

This one was meant to be 4 or 8 bytes depending on whether the containing
unit is 32bit or 64bit DWARF.  If the supplemental file is 64-bit DWARF
and you need to refer to offsets above 4GB in it, the refering unit
needs to be 64-bit as well.
Making it 8 bytes always would reduce its usefulness, it would be less
beneficial to replace common parts (would increase the needed size for the
optimization).

> > Macro Information Header. The macro information entries in the
> > opcode_operands_table may be described in the table. But some cannot be
> > described because some forms are not in the list of allowed forms. In
> > particular DW_FORM_strp_sup is missing so DW_MACRO_define_sup and
> > DW_MACRO_undef_sup cannot be described. And DW_FORM_ref_sup is missing,
> > making it impossible to describe DW_MACRO_import_sup. Which makes the
> > code that checks for allowed forms slightly inconvenient (it should
> > reject these MACRO descriptions if those forms are used in the table,
> > but not if they are defined implicitly). Also DW_FORM_line_strp isn't
> > allowed. But it might be beneficial for describing files referenced by
> > macros.
> 
> Good catch.  I see there is issue 161031.3 which has to do with allowed 
> forms in the line table, but I'm not seeing one for the macro section.

Yes, DW_FORM_ref_sup and DW_FORM_strp_sup certainly should be allowed
in .debug_macro opcode table, likely DW_FORM_line_strp as well.

	Jakub


From arnez@linux.vnet.ibm.com  Thu Dec  1 14:17:16 2016
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Thu, 01 Dec 2016 15:17:16 +0100
Subject: [Dwarf-Discuss] Some DWARFv5 draft feedback
In-Reply-To: <1480555464.3728.214.camel@redhat.com> (Mark Wielaard's message
	of "Thu, 01 Dec 2016 02:24:24 +0100")
References: <1480555464.3728.214.camel@redhat.com>
Message-ID: <m3h96nivir.fsf@oc1027705133.ibm.com>

On Thu, Dec 01 2016, Mark Wielaard wrote:

> BTW. It would be handy if there were sources for the spec so one can
> create patches for simple typos. Also it is somewhat opaque how Issues
> are handled. Could they and any comments from the committee be sent to
> the mailinglist to make tracking changes to the draft easier.

+1.


While we're at it, DWARF5 should improve the description of DW_OP_piece
and DW_OP_bit_piece.  AFAIK, their handling is fairly broken in all
existing DWARF producers and consumers (certainly in GDB -- in multiple
ways!), so even incompatible changes may not cause much harm.  See my
previous mails on this topic:

 http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2016-March/004229.html
 https://sourceware.org/ml/gdb/2016-01/msg00013.html

E.g.:

* DW_OP_bit_piece: [...] "If the location is a register, the offset is
  from the least significant bit end of the register."

  Is it intentional that this differs from the definition of
  DW_OP_piece, where the "placement of the piece within that register is
  defined by the ABI"?  Or can it be assumed (like all current
  producers/consumers do, AFAIK) that DW_OP_piece shall behave as if it
  was a DW_OP_bit_piece with offset 0?  What does the least significant
  bit end even mean, say, for a vector register?  And is this really a
  useful definition for FP registers, where the natural alignment is
  from the *most* significant bit end?

* DW_OP_piece: Some existing producers may emit DW_OP_piece operations
  that exceed the size of a single register, supposedly referring to
  multiple ("consecutive") registers.

  This usage is not covered by the current description of DW_OP_piece.
  Should it be?

--
Andreas



From mjw@redhat.com  Thu Dec  1 17:40:38 2016
From: mjw@redhat.com (Mark Wielaard)
Date: Thu, 01 Dec 2016 18:40:38 +0100
Subject: [Dwarf-Discuss] Some DWARFv5 draft feedback
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEAF4950529@USCULXMSG08.am.sony.com>
References: <1480555464.3728.214.camel@redhat.com>
	<E3B07FDB86BFF041819DC057DEED8FEAF4950529@USCULXMSG08.am.sony.com>
Message-ID: <1480614038.3728.224.camel@redhat.com>

On Thu, 2016-12-01 at 13:52 +0000, Robinson, Paul wrote:
> Thanks for reporting this stuff!  I see a few things you found have
> already been reported, but please make sure to file issues for the
> rest so we can clean up as much as we can.

Thanks, I did also file the following Issues, but they have not yet
shown up on the website. I think these are easily clarified. The rest is
probably more debatable, maybe something to coordinate between consumers
and producers.

For example what and how language specific attributes of DIEs move
between compile and (shared) type or partial units I don't have a good
feeling for (but might be as simple as just recommending producers not
to merge DIEs from CUs with different language attributes and/or adding
the language attribute to the partial unit DIE).

Subject:  Some forms are missing from the opcode_operands_table allowed
forms list
Name:  Mark Wielaard
Email:  mjw at redhat.com
Section:  6.3.1  Page:  166
Type:  Error

The macro information entries in the opcode_operands_table may be
described in the table. But some cannot be described because some forms
are not in the list of allowed forms.

In particular DW_FORM_strp_sup is missing so DW_MACRO_define_sup and
DW_MACRO_undef_sup cannot be described. And DW_FORM_ref_sup is missing,
making it impossible to describe DW_MACRO_import_sup. Also
DW_FORM_line_strp isn't allowed. But it might be beneficial for
describing files referenced by macros.

Add DW_FORM_strp_sup, DW_FORM_ref_sup and DW_FORM_line_strp to the list
of allowed forms at the end of point 4 opcode_operands_table.

Subject:  Add DW_AT_encoding to the attribute list for
DW_TAG_enumeration_type
Name:  Mark Wielaard
Email:  mjw at redhat.com
Section:  Appendix A  Page:  255
Type:  Improvement

It is allowed to have a DW_AT_byte_size on a DW_TAG_enumeration_type,
but not DW_AT_encoding. To describe both size and encoding one needs to
use a DW_AT_type pointing to a base type that represents the "underlying
type".

For languages where enumerations don't have an underlying type, or for
strongly typed enums it is easier to attach the encoding directly than
adding and indirection to a base type.

Add DW_AT_encoding to the attribute list for DW_TAG_enumeration_type.

Subject:  DW_FORM_data16 should be block class, not constant value
class.
Name:  Mark Wielaard
Email:  mjw at redhat.com
Section:  7.5.5  Page:  212
Type:  Improvement

Classifying DW_FORM_data16 as a constant value class and having to
handle a 128bit value everywhere a constant value class is allowed is
somewhat inconvenient. Consumers do already handle such large values as
block and both gdb and elfutils currently handle data16 as (constant
size) block class.

In practice it seems to only impact DW_AT_const_value which can already
take a constant or a block. Using it for other attributes doesn't really
seem to make sense.

Suggest to rename to DW_FORM_data16_block and put it in the block class
instead of the constant class.

Subject:  representation of DW_FORM_strp/DW_FORM_line_strp typo
Name:  Mark Wielaard
Email:  mjw at redhat.com
Section:  7.5.5  Page:  217
Type:  Editorial

Under the bullet point "string" in the second item describing the
representation:

"In the 32-bit DWARF format, the representation of a DW_FORM_strp,
DW_FORM_strp or
DW_FORM_strp_sup value is a 4-byte unsigned offset;"

The second DW_FORM_strp should be DW_FORM_line_strp.

Subject:  Make Unit Headers use less space
Name:  Mark Wielaard
Email:  mjw at redhat.com
Section:  7.5.1  Page:  199
Type:  Improvement

This is an alternative for issue 161031.2. Instead of making the header
size/fields completely depend on the unit type just use some bits to
describe whether or not a unit header has any of the option fields. This
could be as simple as dedicating just the low 6 bits to the actually
unit type and use the upper two bits to indicate whether the header has
an (8 byte) ID field and/or an (4 or 8 byte) DIE offset field.

This allows 64 unit types and makes it easy to describe which optional
fields are in the header for currently unknown new types without wasting
any padding space.

Subject:  Remove DW_LANG_C_plus_plus_03
Name:  Mark Wielaard
Email:  mjw at redhat.com
Section:  7.12  Page:  228
Type:  Error

Language encodings describe different languages, but c++03 (unlike c++11
and c++14) didn't change the language. C++03 is just C++98 with some
DRs. So for producers and consumers c++98 and c++03 look completely
similar. It was originally requested in Issue 120628.1, but the
submitter agreed with the consensus on the dwarf-discuss list to remove
it.

Subject:  Add DW_LANG_C_plus_plus_17
Name:  Mark Wielaard
Email:  mjw at redhat.com
Section:  7.12  Page:  228
Type:  Improvement

c++17 is nearly feature-complete to be finished in 2017. It adds various
language changes and compilers like GCC already implement it almost
completely. Please add DW_LANG_C_plus_plus_17 to the Language Encodings
table.





From eager@eagercon.com  Thu Dec  1 19:32:05 2016
From: eager@eagercon.com (Michael Eager)
Date: Thu, 1 Dec 2016 11:32:05 -0800
Subject: [Dwarf-Discuss] Some DWARFv5 draft feedback
In-Reply-To: <m3h96nivir.fsf@oc1027705133.ibm.com>
References: <1480555464.3728.214.camel@redhat.com>
	<m3h96nivir.fsf@oc1027705133.ibm.com>
Message-ID: <58407AB5.9080308@eagercon.com>

Andreas --

Please submit comments about the Public Draft at http://dwarfstd.org/Comment.php.

On 12/01/2016 06:17 AM, Andreas Arnez wrote:
> On Thu, Dec 01 2016, Mark Wielaard wrote:
>
>> BTW. It would be handy if there were sources for the spec so one can
>> create patches for simple typos. Also it is somewhat opaque how Issues
>> are handled. Could they and any comments from the committee be sent to
>> the mailinglist to make tracking changes to the draft easier.
>
> +1.
>
>
> While we're at it, DWARF5 should improve the description of DW_OP_piece
> and DW_OP_bit_piece.  AFAIK, their handling is fairly broken in all
> existing DWARF producers and consumers (certainly in GDB -- in multiple
> ways!), so even incompatible changes may not cause much harm.  See my
> previous mails on this topic:
>
>   http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2016-March/004229.html
>   https://sourceware.org/ml/gdb/2016-01/msg00013.html
>
> E.g.:
>
> * DW_OP_bit_piece: [...] "If the location is a register, the offset is
>    from the least significant bit end of the register."
>
>    Is it intentional that this differs from the definition of
>    DW_OP_piece, where the "placement of the piece within that register is
>    defined by the ABI"?  Or can it be assumed (like all current
>    producers/consumers do, AFAIK) that DW_OP_piece shall behave as if it
>    was a DW_OP_bit_piece with offset 0?  What does the least significant
>    bit end even mean, say, for a vector register?  And is this really a
>    useful definition for FP registers, where the natural alignment is
>    from the *most* significant bit end?
>
> * DW_OP_piece: Some existing producers may emit DW_OP_piece operations
>    that exceed the size of a single register, supposedly referring to
>    multiple ("consecutive") registers.
>
>    This usage is not covered by the current description of DW_OP_piece.
>    Should it be?
>
> --
> Andreas
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>


-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


From eager@eagercon.com  Sun Dec  4 01:37:17 2016
From: eager@eagercon.com (Michael Eager)
Date: Sat, 3 Dec 2016 17:37:17 -0800
Subject: [Dwarf-Discuss] Some DWARFv5 draft feedback
In-Reply-To: <1480555464.3728.214.camel@redhat.com>
References: <1480555464.3728.214.camel@redhat.com>
Message-ID: <5843734D.5040706@eagercon.com>

On 11/30/2016 05:24 PM, Mark Wielaard wrote:
> BTW. It would be handy if there were sources for the spec so one can
> create patches for simple typos. Also it is somewhat opaque how Issues
> are handled. Could they and any comments from the committee be sent to
> the mailinglist to make tracking changes to the draft easier.

Sources for the document will be available on the DWARF website
when the document is finalized.

Generally, when an issue is resolved (either adopted, adopted with
modificaitons, or rejected) comments are added to the issue which
describe the resolution.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


From aaronrobinson@nokomis.k12.il.us  Mon Dec  5 17:53:23 2016
From: aaronrobinson@nokomis.k12.il.us (Aaron Robinson)
Date: Mon, 5 Dec 2016 11:53:23 -0600
Subject: [Dwarf-Discuss] Dwarf-Discuss Digest, Vol 94, Issue 4
In-Reply-To: <mailman.1.1480871089.14559.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
References: <mailman.1.1480871089.14559.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
Message-ID: <CAOgs1vq+7uFQQ05uWksu5Ei9hxf1gw5F2DdZXk2Xhdbz-1U1Xw@mail.gmail.com>

Have you watched the 2007 hit film, "Bee Movie"?

*-Aarioni*

On Sun, Dec 4, 2016 at 11:04 AM, <dwarf-discuss-request at lists.dwarfstd.org>
wrote:

> Send Dwarf-Discuss mailing list submissions to
>         dwarf-discuss at lists.dwarfstd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> or, via email, send a message with subject or body 'help' to
>         dwarf-discuss-request at lists.dwarfstd.org
>
> You can reach the person managing the list at
>         dwarf-discuss-owner at lists.dwarfstd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dwarf-Discuss digest..."
>
>
> Today's Topics:
>
>    1. Re: Some DWARFv5 draft feedback (Michael Eager)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 3 Dec 2016 17:37:17 -0800
> From: Michael Eager <eager at eagercon.com>
> To: Mark Wielaard <mjw at redhat.com>,     DWARF Discuss
>         <dwarf-discuss at lists.dwarfstd.org>
> Subject: Re: [Dwarf-Discuss] Some DWARFv5 draft feedback
> Message-ID: <5843734D.5040706 at eagercon.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 11/30/2016 05:24 PM, Mark Wielaard wrote:
> > BTW. It would be handy if there were sources for the spec so one can
> > create patches for simple typos. Also it is somewhat opaque how Issues
> > are handled. Could they and any comments from the committee be sent to
> > the mailinglist to make tracking changes to the draft easier.
>
> Sources for the document will be available on the DWARF website
> when the document is finalized.
>
> Generally, when an issue is resolved (either adopted, adopted with
> modificaitons, or rejected) comments are added to the issue which
> describe the resolution.
>
> --
> Michael Eager    eager at eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>
> ------------------------------
>
> End of Dwarf-Discuss Digest, Vol 94, Issue 4
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20161205/5ae7b796/attachment.htm>


From arnez@linux.vnet.ibm.com  Tue Dec  6 18:56:27 2016
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Tue, 06 Dec 2016 19:56:27 +0100
Subject: [Dwarf-Discuss] Some DWARFv5 draft feedback
References: <1480555464.3728.214.camel@redhat.com>
	<m3h96nivir.fsf@oc1027705133.ibm.com> <58407AB5.9080308@eagercon.com>
Message-ID: <m3eg1krin8.fsf@oc1027705133.ibm.com>

On Thu, Dec 01 2016, Michael Eager wrote:

> Andreas --
>
> Please submit comments about the Public Draft at http://dwarfstd.org/Comment.php.

OK, I've submitted three requests for clarifying separate aspects of the
DW_OP_piece and DW_OP_bit_piece operations.

--
Andreas



From aaronrobinson@nokomis.k12.il.us  Wed Dec  7 17:13:43 2016
From: aaronrobinson@nokomis.k12.il.us (Aaron Robinson)
Date: Wed, 7 Dec 2016 11:13:43 -0600
Subject: [Dwarf-Discuss] Dwarf-Discuss Digest, Vol 94, Issue 6
In-Reply-To: <mailman.1.1481130263.10303.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
References: <mailman.1.1481130263.10303.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
Message-ID: <CAOgs1vp6F6Bo_eAz29xw+xE52geKG9+Bikhyn8N5eoZvUeF=zQ@mail.gmail.com>

Dank.

*-Aarioni*

On Wed, Dec 7, 2016 at 11:04 AM, <dwarf-discuss-request at lists.dwarfstd.org>
wrote:

> Send Dwarf-Discuss mailing list submissions to
>         dwarf-discuss at lists.dwarfstd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> or, via email, send a message with subject or body 'help' to
>         dwarf-discuss-request at lists.dwarfstd.org
>
> You can reach the person managing the list at
>         dwarf-discuss-owner at lists.dwarfstd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dwarf-Discuss digest..."
>
>
> Today's Topics:
>
>    1. Re: Some DWARFv5 draft feedback (Andreas Arnez)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 06 Dec 2016 19:56:27 +0100
> From: Andreas Arnez <arnez at linux.vnet.ibm.com>
> To: Michael Eager <eager at eagercon.com>
> Cc: DWARF Discuss <dwarf-discuss at lists.dwarfstd.org>,   elfutils
>         development <elfutils-devel at lists.fedorahosted.org>,    Mark
> Wielaard
>         <mjw at redhat.com>
> Subject: Re: [Dwarf-Discuss] Some DWARFv5 draft feedback
> Message-ID: <m3eg1krin8.fsf at oc1027705133.ibm.com>
> Content-Type: text/plain
>
> On Thu, Dec 01 2016, Michael Eager wrote:
>
> > Andreas --
> >
> > Please submit comments about the Public Draft at
> http://dwarfstd.org/Comment.php.
>
> OK, I've submitted three requests for clarifying separate aspects of the
> DW_OP_piece and DW_OP_bit_piece operations.
>
> --
> Andreas
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>
> ------------------------------
>
> End of Dwarf-Discuss Digest, Vol 94, Issue 6
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20161207/1440b106/attachment.htm>


From arnez@linux.vnet.ibm.com  Fri Dec  9 19:11:18 2016
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Fri, 09 Dec 2016 20:11:18 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
Message-ID: <m3r35gq5nt.fsf@oc1027705133.ibm.com>

Although I've already created public comments for (most of) this,
Michael Eager suggested that I post my questions regarding DWARF pieces
on this list (again).

All of these questions are related to the definition of DW_OP_piece and
DW_OP_bit_piece:

* Is "DW_OP_piece(n)" equivalent to "DW_OP_bit_piece(8*n, 0)"?

* What is the correct placement rule for register pieces?  ABI-defined
  or lsb0-ordered?  If lsb0-ordered, how exactly is that order defined
  for non-integer registers?

* Shall DW_OP_bit_piece ignore the offset for stack- and implicit
  values?

* What is the "least significant bit" of an implicit value?  And is it
  intentional that the placement rule differs between implicit- and
  memory values?

* Some DWARF producers describe a register pair just with a single
  DW_OP_reg<n>.  Can a register piece reach into the next register like
  that as well?

* Is "DW_OP_reg*" followed by "DW_OP_piece(size of object type)" always
  equivalent to omitting the piece operation?

--
Andreas



From aprantl@apple.com  Fri Dec  9 19:46:31 2016
From: aprantl@apple.com (Adrian Prantl)
Date: Fri, 09 Dec 2016 11:46:31 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
Message-ID: <93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>

Here's my take on this.


> On Dec 9, 2016, at 11:11 AM, Andreas Arnez <arnez at linux.vnet.ibm.com> wrote:
> 
> Although I've already created public comments for (most of) this,
> Michael Eager suggested that I post my questions regarding DWARF pieces
> on this list (again).
> 
> All of these questions are related to the definition of DW_OP_piece and
> DW_OP_bit_piece:
> 
> * Is "DW_OP_piece(n)" equivalent to "DW_OP_bit_piece(8*n, 0)"?

I would think the answer to this is yes, and if it isn't I would really like to see the counterexample added to the Appendix.

> 
> * What is the correct placement rule for register pieces?  ABI-defined
>  or lsb0-ordered?  If lsb0-ordered, how exactly is that order defined
>  for non-integer registers?

"If the location is a register, the offset is from the least significant bit end of the register."
Does this text from the latest draft answer the question?
If not, can you give an example where it isn't?

> 
> * Shall DW_OP_bit_piece ignore the offset for stack- and implicit
>  values?

"If the location is any implicit value or stack value, the DW_OP_bit_piece operation describes a sequence of bits using the least significant bits of that value."

No.

> 
> * What is the "least significant bit" of an implicit value?  And is it
>  intentional that the placement rule differs between implicit- and
>  memory values?

I don't know.

> 
> * Some DWARF producers describe a register pair just with a single
>  DW_OP_reg<n>.  Can a register piece reach into the next register like
>  that as well?

You mean for a pair of r1,r2 they would emit only DW_OP_reg1? I don't think this use is supported by the DWARF specification.

> 
> * Is "DW_OP_reg*" followed by "DW_OP_piece(size of object type)" always
>  equivalent to omitting the piece operation?

If sizeof(obj) == sizeof(reg) it is obviously.
If sizeof(obj) > sizeof(reg) the expression is malformed because there are undefined bits in the object that should have been represented with an empty DW_OP_piece.
If sizeof(obj) < sizeof(reg) the expression is overspecified, but still sound, so I would say yes.

-- adrian

> 
> --
> Andreas
> 
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



From arnez@linux.vnet.ibm.com  Mon Dec 12 14:28:22 2016
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Mon, 12 Dec 2016 15:28:22 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com> (Adrian Prantl's
	message of "Fri, 09 Dec 2016 11:46:31 -0800")
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
Message-ID: <m3y3zl6x2x.fsf@oc1027705133.ibm.com>

On Fri, Dec 09 2016, Adrian Prantl wrote:

> Here's my take on this.

Thanks!

>> On Dec 9, 2016, at 11:11 AM, Andreas Arnez <arnez at linux.vnet.ibm.com> wrote:
>> 
>> Although I've already created public comments for (most of) this,
>> Michael Eager suggested that I post my questions regarding DWARF pieces
>> on this list (again).
>> 
>> All of these questions are related to the definition of DW_OP_piece and
>> DW_OP_bit_piece:
>> 
>> * Is "DW_OP_piece(n)" equivalent to "DW_OP_bit_piece(8*n, 0)"?
>
> I would think the answer to this is yes, and if it isn't I would
> really like to see the counterexample added to the Appendix.

Right, I think clarification would be appropriate either way.

Does anybody vote for "no"?

>> * What is the correct placement rule for register pieces?  ABI-defined
>>  or lsb0-ordered?  If lsb0-ordered, how exactly is that order defined
>>  for non-integer registers?
>
> "If the location is a register, the offset is from the least
> significant bit end of the register."
> Does this text from the latest draft answer the question?
> If not, can you give an example where it isn't?

The definition of DW_OP_piece differs, though: "[...] the placement of
the piece within that register is defined by the ABI."

>> * Shall DW_OP_bit_piece ignore the offset for stack- and implicit
>>  values?
>
> "If the location is any implicit value or stack value, the
> DW_OP_bit_piece operation describes a sequence of bits using the least
> significant bits of that value."
>
> No.

Really?  IMHO the wording implies that the least significant bit always
belongs to the piece.

>> * What is the "least significant bit" of an implicit value?  And is it
>>  intentional that the placement rule differs between implicit- and
>>  memory values?
>
> I don't know.
>
>> 
>> * Some DWARF producers describe a register pair just with a single
>>  DW_OP_reg<n>.  Can a register piece reach into the next register like
>>  that as well?
>
> You mean for a pair of r1,r2 they would emit only DW_OP_reg1? I don't
> think this use is supported by the DWARF specification.

OK.  Are there other opinions?

>> * Is "DW_OP_reg*" followed by "DW_OP_piece(size of object type)" always
>>  equivalent to omitting the piece operation?
>
> If sizeof(obj) == sizeof(reg) it is obviously.
> If sizeof(obj) > sizeof(reg) the expression is malformed because there
> are undefined bits in the object that should have been represented
> with an empty DW_OP_piece.

GCC may describe a long double struct member on x86 as

  DW_OP_regx: 33 (st0); DW_OP_piece: 16

where st0 is only 10 bytes wide.  Is that invalid then?

> If sizeof(obj) < sizeof(reg) the expression is overspecified, but
> still sound, so I would say yes.

So you'd say the placement rules for DW_OP_reg* and DW_OP_piece shall be
compatible, both defined by the ABI -- not necessarily lsb0-ordered?
And the bytes referred to by a "DW_OP_reg*"-location may depend on the
object's size, but not its type, right?

Note that this wouldn't work well with cases like the "SPU preferred
slots"; see https://sourceware.org/ml/gdb/2016-01/msg00013.html, section
2.2.

--
Andreas



