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: m...@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: m...@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: m...@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: m...@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: m...@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: m...@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: m...@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. _______________________________________________ elfutils-devel mailing list -- elfutils-devel@lists.fedorahosted.org To unsubscribe send an email to elfutils-devel-le...@lists.fedorahosted.org