[llvm-dev] Invalid DW_AT_calling_convention generated for a DW_TAG_class_type

[via llvm-dev]

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