[llvm] r200569 - DebugInfo: Flag type unit references as declarations
Robinson, Paul
Paul_Robinson at playstation.sony.com
Fri Jan 31 14:35:48 PST 2014
Well, it seems wrong mainly because the description of DW_AT_signature says it applies to incomplete types.
A definition of a class member (static data member, or method) would normally have a DW_AT_specification referring to the declaration. But in this case the declaration is buried inside a type unit, and the only thing you can refer to from outside the type unit is the type as a whole, via DW_AT_signature.
I'm astonished that GCC hasn't run into this already. Or is that where the idea for the DW_AT_declaration hack came from? Whining about this to Cary might help you feel better. :)
Who gets to file the issue with the DWARF committee?
--paulr
From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Friday, January 31, 2014 2:17 PM
To: Robinson, Paul
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm] r200569 - DebugInfo: Flag type unit references as declarations
On Fri, Jan 31, 2014 at 2:08 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:
This just seems wrong.
How so? (yeah, I'd sort of like it if the debugger assumed that a DW_TAG_class/structure with a DW_AT_signature was assumed to be a declaration (of sorts)) I can think of a few ways it seems wrong, but curious what you've got in mind.
What prompted it?
Several failures in gdb.cp/m-static.exp in the GDB 7.5 test suite. (there's still one more failure I'm investigating most likely due to missing DW_AT_stmt_list on type units)
The story goes something like this:
* Type goes in a type unit.
* 'skeletal' type (DW_TAG_class with a DW_AT_signature) goes in the compile unit.
* but now you want to reference one of the members of the type from within the compile unit (in m-static's case, it's because you have an out-of-line definition of a static member variable), so insert a declaration of that particular member into the 'skeletal' type.
This freaks out GDB because it assumes the type with members (even though it has DW_AT_signature) is a definition, it seems.
I can roll back the patch locally to show/demonstrate more specifically what the failure mode is.
--paulr
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu<mailto:llvm-commits-bounces at cs.uiuc.edu> [mailto:llvm-commits-<mailto:llvm-commits->
> bounces at cs.uiuc.edu<mailto:bounces at cs.uiuc.edu>] On Behalf Of David Blaikie
> Sent: Friday, January 31, 2014 11:52 AM
> To: llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
> Subject: [llvm] r200569 - DebugInfo: Flag type unit references as
> declarations
>
> Author: dblaikie
> Date: Fri Jan 31 13:52:26 2014
> New Revision: 200569
>
> URL: http://llvm.org/viewvc/llvm-project?rev=200569&view=rev
> Log:
> DebugInfo: Flag type unit references as declarations
>
> This ensures DWARF consumers don't confuse these references for
> definitions. I'd argue it might be nice to improve debuggers so we don't
> need this, but it's just one field in an abbreviation anyway - so it
> doesn't seem worth the fight.
>
> Modified:
> llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
> llvm/trunk/test/DebugInfo/X86/generate-odr-hash.ll
>
> Modified: llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp?rev=200569&r1=2
> 00568&r2=200569&view=diff
> ========================================================================
> ======
> --- llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp (original)
> +++ llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp Fri Jan 31 13:52:26
> 2014
> @@ -3016,6 +3016,11 @@ void DwarfDebug::emitDebugStrDWO() {
> void DwarfDebug::addDwarfTypeUnitType(DICompileUnit CUNode,
> StringRef Identifier, DIE
> *RefDie,
> DICompositeType CTy) {
> + // Flag the type unit reference as a declaration so that if it
> contains
> + // members (implicit special members, static data member definitions,
> member
> + // declarations for definitions in this CU, etc) consumers don't get
> confused
> + // and think this is a full definition.
> + CUMap.begin()->second->addFlag(RefDie, dwarf::DW_AT_declaration);
>
> const DwarfTypeUnit *&TU = DwarfTypeUnits[CTy];
> if (TU) {
>
> Modified: llvm/trunk/test/DebugInfo/X86/generate-odr-hash.ll
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/test/DebugInfo/X86/generate-odr-
> hash.ll?rev=200569&r1=200568&r2=200569&view=diff
> ========================================================================
> ======
> --- llvm/trunk/test/DebugInfo/X86/generate-odr-hash.ll (original)
> +++ llvm/trunk/test/DebugInfo/X86/generate-odr-hash.ll Fri Jan 31
> 13:52:26 2014
> @@ -51,8 +51,10 @@
> ; CHECK: Compile Unit: length = [[CU_SIZE:[0-9a-f]+]]
>
> ; CHECK: DW_TAG_structure_type
> +; CHECK-NEXT: DW_AT_declaration
> ; CHECK-NEXT: DW_AT_signature
> ; CHECK: DW_TAG_class_type
> +; CHECK-NEXT: DW_AT_declaration
> ; CHECK-NEXT: DW_AT_signature
>
> ; Ensure the CU-local type 'walrus' is not placed in a type unit.
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140131/fc971e9e/attachment.html>
More information about the llvm-commits
mailing list