[llvm] r200569 - DebugInfo: Flag type unit references as declarations

[David Blaikie]

On Fri, Jan 31, 2014 at 2:35 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

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

Right - so we put just the necessary member declaration inside the type
declaration and have the out of line definition's DW_AT_signature refer to
that member declaration.


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

This is what GCC does too, yes.

Actually GCC does about 3 or 4 different ways to refer to a type unit:

If there are few (1?) references to a type, the DW_AT_type just uses a
DW_FORM_ref_sig8 directly.
If there are several, a stub DW_AT_class/structure at the top level
(underneath the compile_unit) with a single DW_AT_signature
If there are members definitions that need to refer to declarations, the
stub is placed in the correct DW_TAG_namespaces, includes a
DW_AT_declaration, and even a DW_AT_name.

Clang currently does something in between - mostly like the 3rd option, the
stub goes in the right namespace, but doesn't include the type name (though
as of this patch, includes the DW_AT_declaration). This is mostly just a
convenient quirk of implementation (that we put it in the fully qualified
namespace) - if we found that to be a substantial space savings, we could
remove that too, but I didn't want to bother with that until I had some
justification.

GDB was already swallowing DWARF like this (at least with
DW_AT_declaration) without type units for the vtable optimization (your
type has a key function not defined in this TU, so the type definition is
not emitted here (only a declaration) - but you have some member definition
in this TU (especially - an implicit special member of member template
instantiation, but possibly any other member defintion such as a static
member variable, or member function) so GCC and Clang both emit just the
necessary member declaration into the type declaration and the out of line
definition can refer to that declaration).



>   Whining about this to Cary might help you feel better. J
>
>
>
> 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> 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] On Behalf Of David Blaikie
> > Sent: Friday, January 31, 2014 11:52 AM
> > To: 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
> > 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/f18e72fe/attachment.html>