Re: [Dwarf-Discuss] Some DWARFv5 draft feedback

Re: [Dwarf-Discuss] Some DWARFv5 draft feedback

[Andreas Arnez]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

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

Re: [Dwarf-Discuss] Some DWARFv5 draft feedback

[Andreas Arnez]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

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

Re: [Dwarf-Discuss] Some DWARFv5 draft feedback

[Michael Eager]

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

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


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

Re: [Dwarf-Discuss] Some DWARFv5 draft feedback

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 5077 bytes --]

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

Re: [Dwarf-Discuss] Some DWARFv5 draft feedback

[Jakub Jelinek]

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

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

RE: [Dwarf-Discuss] Some DWARFv5 draft feedback

[Robinson, Paul]

[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]

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

Re: [Dwarf-Discuss] Some DWARFv5 draft feedback

[Todd Allen]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

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