llvm dev - Jul 2019 - Invalid DW_AT_calling_convention generated for a DW_TAG_class_type

In llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, the compiler can emit a
DW_AT_calling_convention attribute with a DW_TAG_class_type (and it looks like a
DW_TAG_variant_part, DW_TAG_structure_type or DW_TAG_union_type as well), but
the DWARF 4 specification says that DW_AT_calling_convention is not a valid
attribute for any of those three DWARF tags.

Downstream object consumers that check to verify that a DWARF attr is
appropriate for a given DWARF tag will appropriately flag an error.

I conjecture that this part of the DwarfUnit::constructTypeDIe() function (circa
line 958 in DwarfUnit.cpp) should be guarded with a target- or vendor-specific
conditional if it is needed for a particular purpose. Otherwise, I propose that
it be removed since it breaks compliance with the DWARF specification.

~ Todd Snider


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/1e12d07c/attachment.html>

I see now that this is a DWARF 5 addition. It is still invalid for DWARF 4 or
earlier.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Snider,
Todd via llvm-dev
Sent: Tuesday, July 30, 2019 11:54 AM
To: llvm-dev
Subject: [EXTERNAL] [llvm-dev] Invalid DW_AT_calling_convention generated for a
DW_TAG_class_type


In llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, the compiler can emit a
DW_AT_calling_convention attribute with a DW_TAG_class_type (and it looks like a
DW_TAG_variant_part, DW_TAG_structure_type or DW_TAG_union_type as well), but
the DWARF 4 specification says that DW_AT_calling_convention is not a valid
attribute for any of those three DWARF tags.

Downstream object consumers that check to verify that a DWARF attr is
appropriate for a given DWARF tag will appropriately flag an error.

I conjecture that this part of the DwarfUnit::constructTypeDIe() function (circa
line 958 in DwarfUnit.cpp) should be guarded with a target- or vendor-specific
conditional if it is needed for a particular purpose. Otherwise, I propose that
it be removed since it breaks compliance with the DWARF specification.

~ Todd Snider


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/51fd2b0e/attachment.html>

>Downstream object consumers that check to verify that a DWARF attr is
appropriate for a given DWARF tag will appropriately flag an error.
Such a downstream consumer is behaving inappropriately.  DWARF is a
"permissive" standard, and the use of an attribute in a novel
situation is explicitly permitted (see section 1.3 of DWARF v4).  Consumers are
expected to ignore tags and attributes that they do not recognize.

The sort of verification you describe might be appropriate for a producer that
supported a "strict DWARF" mode, and used only those tags, attributes,
and combinations that are explicitly described in a given DWARF version.  LLVM
does not have such a mode, and the DWARF specification does not require it.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Snider,
Todd via llvm-dev
Sent: Tuesday, July 30, 2019 12:59 PM
To: llvm-dev
Subject: Re: [llvm-dev] Invalid DW_AT_calling_convention generated for a
DW_TAG_class_type

I see now that this is a DWARF 5 addition. It is still invalid for DWARF 4 or
earlier.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Snider,
Todd via llvm-dev
Sent: Tuesday, July 30, 2019 11:54 AM
To: llvm-dev
Subject: [EXTERNAL] [llvm-dev] Invalid DW_AT_calling_convention generated for a
DW_TAG_class_type


In llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, the compiler can emit a
DW_AT_calling_convention attribute with a DW_TAG_class_type (and it looks like a
DW_TAG_variant_part, DW_TAG_structure_type or DW_TAG_union_type as well), but
the DWARF 4 specification says that DW_AT_calling_convention is not a valid
attribute for any of those three DWARF tags.

Downstream object consumers that check to verify that a DWARF attr is
appropriate for a given DWARF tag will appropriately flag an error.

I conjecture that this part of the DwarfUnit::constructTypeDIe() function (circa
line 958 in DwarfUnit.cpp) should be guarded with a target- or vendor-specific
conditional if it is needed for a particular purpose. Otherwise, I propose that
it be removed since it breaks compliance with the DWARF specification.

~ Todd Snider


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/1c8a6db1/attachment.html>