[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