via llvm-dev
2019-Jul-30 17:46 UTC
[llvm-dev] Invalid DW_AT_calling_convention generated for a DW_TAG_class_type
>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>
Adrian Prantl via llvm-dev
2019-Jul-30 18:18 UTC
[llvm-dev] Invalid DW_AT_calling_convention generated for a DW_TAG_class_type
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. -- adrian
Snider, Todd via llvm-dev
2019-Jul-30 19:01 UTC
[llvm-dev] [EXTERNAL] Re: Invalid DW_AT_calling_convention generated for a DW_TAG_class_type
Paul, 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. Thanks to you both! ~ Todd -----Original Message----- From: aprantl at apple.com [mailto:aprantl at apple.com] Sent: Tuesday, July 30, 2019 1:18 PM To: paul.robinson at sony.com Cc: Snider, Todd; llvm-dev at lists.llvm.org Subject: [EXTERNAL] Re: [llvm-dev] Invalid DW_AT_calling_convention generated for a DW_TAG_class_type 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. -- adrian