Re: [Dwarf-Discuss] Some DWARFv5 draft feedback

[Mark Wielaard <mjw at redhat dot 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@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.