Re: [Dwarf-Discuss] Some DWARFv5 draft feedback
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 ___ elfutils-devel mailing list -- elfutils-devel@lists.fedorahosted.org To unsubscribe send an email to elfutils-devel-le...@lists.fedorahosted.org
Re: [Dwarf-Discuss] Some DWARFv5 draft feedback
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-disc...@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 ___ elfutils-devel mailing list -- elfutils-devel@lists.fedorahosted.org To unsubscribe send an email to elfutils-devel-le...@lists.fedorahosted.org
Re: [Dwarf-Discuss] Some DWARFv5 draft feedback
On Thu, 2016-12-01 at 13:52 +, 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. __
Re: [Dwarf-Discuss] Some DWARFv5 draft feedback
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 ___ elfutils-devel mailing list -- elfutils-devel@lists.fedorahosted.org To unsubscribe send an email to elfutils-devel-le...@lists.fedorahosted.org
Re: [Dwarf-Discuss] Some DWARFv5 draft feedback
On Thu, Dec 01, 2016 at 01:52:47PM +, 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 ___ elfutils-devel mailing list -- elfutils-devel@lists.fedorahosted.org To unsubscribe send an email to elfutils-devel-le...@lists.fedorahosted.org
RE: [Dwarf-Discuss] Some DWARFv5 draft feedback
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 ___ elfutils-devel mailing list -- elfutils-devel@lists.fedorahosted.org To unsubscribe send an email to elfutils-devel-le...@lists.fedorahosted.org
Re: [Dwarf-Discuss] Some DWARFv5 draft feedback
> > 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 ___ elfutils-devel mailing list -- elfutils-devel@lists.fedorahosted.org To unsubscribe send an email to elfutils-devel-le...@lists.fedorahosted.org