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.
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.
If you have a client that cannot handle the attribute you may want to add a new debugger tuning setting for your customer or a generic "strict" debugger tuning setting that avoids emitting newer attributes when older standards are requested.
Thanks for the info. The object consumer from the toolchain that I am using only flags the error when built in development mode, but even that violates the "permissiveness" rule you cited in an earlier e-mail (section 1.3 of v4).
Adrian,
I will downgrade the diagnostic that is being emitted by my toolchain's object consumer in light of what Paul has advised.