r221704 - PR16091 continued: Debug Info for member functions with undeduced return types.
Robinson, Paul
Paul_Robinson at playstation.sony.com
Tue Nov 11 17:57:32 PST 2014
IR consistency => LTO deduplicates properly; for type units it shows up only in the skeleton for the defining CU. Excellent!
Thanks,
--paulr
From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Tuesday, November 11, 2014 4:51 PM
To: Robinson, Paul
Cc: cfe-commits at cs.uiuc.edu
Subject: Re: r221704 - PR16091 continued: Debug Info for member functions with undeduced return types.
On Tue, Nov 11, 2014 at 4:14 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:
> -----Original Message-----
> From: cfe-commits-bounces at cs.uiuc.edu<mailto:cfe-commits-bounces at cs.uiuc.edu> [mailto:cfe-commits-<mailto:cfe-commits->
> bounces at cs.uiuc.edu<mailto:bounces at cs.uiuc.edu>] On Behalf Of David Blaikie
> Sent: Tuesday, November 11, 2014 12:45 PM
> To: cfe-commits at cs.uiuc.edu<mailto:cfe-commits at cs.uiuc.edu>
> Subject: r221704 - PR16091 continued: Debug Info for member functions with
> undeduced return types.
>
> Author: dblaikie
> Date: Tue Nov 11 14:44:45 2014
> New Revision: 221704
>
> URL: http://llvm.org/viewvc/llvm-project?rev=221704&view=rev
> Log:
> PR16091 continued: Debug Info for member functions with undeduced return
> types.
>
> So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type
> with DW_AT_name "auto", and GCC implements this somewhat, but it
> presents a few problems to do this with Clang.
>
> GCC's implementation only applies to member functions where the auto
> return type isn't deduced immediately (ie: member functions of templates
> or member functions defined out of line). In the common case of an
> inline deduced return type function, GCC emits the DW_AT_type as the
> deduced return type.
>
> Currently GDB doesn't seem to behave too well with this debug info - it
> treats the return type as 'void', even though the definition of the
> function has the correctly deduced return type (I guess it sees the
> return type the declaration has, doesn't understand it, and assumes
> void). This means the function's ABI might be broken (non-trivial return
> types, etc), etc.
>
> Clang, on the other hand doesn't track this particular case of a
> deducable return type that is deduced immediately versus one that is
> deduced 'later'. So if we implement the DWARF5 representation, all
> deducible return type functions would get adverse GDB behavior
> (including deduced return type lambda functions, inline deduced return
> type functions, etc).
>
> Also, we can't just do this for auto types that are not deduced -
> because Clang marks even the declaration's return type as deduced (&
> provides the underlying type) once a definition is seen that allows the
> deduction. So we have to ignore even deduced types - but we can't do
> that for auto variables (because this representation only applies to
> function declarations - variables and function definitions need the real
> type so the function can be called, etc) so we'd need to add an extra
> flag to the type unwrapping/creation code to indicate when we want to
> see through deduced types and when we don't. It's also not as simple as
> just checking at the top level when building a function type (for one
> thing, we reuse the function type building for building function pointer
> types which might also have 'auto' in them - but be the type of a
> variable instead) because the auto might be arbitrarily deeply nested
> ("auto &", "auto (*)()", etc...)
>
> So, with all that said, let's do the simple thing that works in existing
> debuggers for now and treat these functions the same way we do function
> templates and implicit special members: omit them from the member list,
> since they can't be correctly called anyway (without knowing the return
> type the ABI isn't know and a function call could put the arguments in
> the wrong place) so they're not much use to the user.
In summary: all auto-return-type functions are omitted from the class,
whether or not the CU has a definition? That provides the consistency we
need for type units and LTO deduplication.
At the IR level, yes - but because those definitions still refer to the class as their scope, they are still "within" the class, they just aren't in the class's member list.
This is how we do template instantiations and implicit special members - it means when we build the class definition from the top-down (using its member list) we don't see these members, but later on when we build these special members we just insert them into the scope they requested.
I see from the test that there's still metadata for the definition; where
does that end up as far as the DWARF is concerned?
What this all means is that if you don't have type units enabled, you'll see this:
DW_TAG_compile_unit
DW_TAG_structure_type
DW_AT_name
DW_AT_byte_size
...
DW_TAG_member
...
If you have a type unit, you'll get:
DW_TAG_type_unit
DW_TAG_structure_type
DW_AT_name
DW_AT_byte_size
...
DW_TAG_compile_unit
DW_TAG_structure_type
DW_AT_declaration
DW_AT_signature
DW_TAG_member
...
This is the same basic structure you'd see for member function templates and implicit special members - the member declarations will be attached to the struct declaration which references the type unit and the type unit will not contain any mention of them in any translation unit. (that way the type unit is consistent between source files whether or not they instantiate implicit special members, member function templates, or contain static variable definitions/references)
- David
--paulr
>
> At some point in the future, when GDB understands the DWARF5
> representation better it might be worth plumbing through the extra type
> builder handling to avoid looking through AutoType for some callers,
> etc...
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-cxx1y.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=221704&r1=221703&r2=2217
> 04&view=diff
> ==========================================================================
> ====
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Nov 11 14:44:45 2014
> @@ -1175,6 +1175,10 @@ void CGDebugInfo::CollectCXXMemberFuncti
> // referenced)
> if (!Method || Method->isImplicit())
> continue;
> +
> + if (Method->getType()->getAs<FunctionProtoType>()-
> >getContainedAutoType())
> + continue;
> +
> // Reuse the existing member function declaration if it exists.
> // It may be associated with the declaration of the type & should be
> // reused as we're building the definition.
> @@ -2013,8 +2017,7 @@ static QualType UnwrapTypeForDebugInfo(Q
> break;
> case Type::Auto:
> QualType DT = cast<AutoType>(T)->getDeducedType();
> - if (DT.isNull())
> - return T;
> + assert(!DT.isNull() && "Undeduced types shouldn't reach here.");
> T = DT;
> break;
> }
> @@ -2106,8 +2109,6 @@ llvm::DIType CGDebugInfo::CreateTypeNode
> if (Ty.hasLocalQualifiers())
> return CreateQualifiedType(Ty, Unit);
>
> - const char *Diag = nullptr;
> -
> // Work out details of type.
> switch (Ty->getTypeClass()) {
> #define TYPE(Class, Base)
> @@ -2167,6 +2168,7 @@ llvm::DIType CGDebugInfo::CreateTypeNode
> case Type::TemplateSpecialization:
> return CreateType(cast<TemplateSpecializationType>(Ty), Unit);
>
> + case Type::Auto:
> case Type::Attributed:
> case Type::Elaborated:
> case Type::Paren:
> @@ -2176,18 +2178,10 @@ llvm::DIType CGDebugInfo::CreateTypeNode
> case Type::Decltype:
> case Type::UnaryTransform:
> case Type::PackExpansion:
> - llvm_unreachable("type should have been unwrapped!");
> - case Type::Auto:
> - Diag = "auto";
> break;
> }
>
> - assert(Diag && "Fall through without a diagnostic?");
> - unsigned DiagID = CGM.getDiags().getCustomDiagID(
> - DiagnosticsEngine::Error,
> - "debug information for %0 is not yet supported");
> - CGM.getDiags().Report(DiagID) << Diag;
> - return llvm::DIType();
> + llvm_unreachable("type should have been unwrapped!");
> }
>
> /// getOrCreateLimitedType - Get the type from the cache or create a new
>
> Modified: cfe/trunk/test/CodeGenCXX/debug-info-cxx1y.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-
> info-cxx1y.cpp?rev=221704&r1=221703&r2=221704&view=diff
> ==========================================================================
> ====
> --- cfe/trunk/test/CodeGenCXX/debug-info-cxx1y.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-cxx1y.cpp Tue Nov 11 14:44:45
> 2014
> @@ -1,7 +1,20 @@
> -// RUN: not %clang_cc1 -emit-llvm-only -std=c++1y -g %s 2>&1 | FileCheck
> %s
> +// RUN: %clang_cc1 -emit-llvm-only -std=c++14 -emit-llvm -g %s -o - |
> FileCheck %s
> +
> +// CHECK: [[EMPTY:![0-9]*]] = metadata !{}
> +// CHECK: \00foo\00{{.*}}, metadata [[EMPTY]], {{.*}}} ; [
> DW_TAG_structure_type ]
> +// FIXME: The context of this definition should be the CU/file scope, not
> the class.
> +// CHECK: metadata !"_ZTS3foo", metadata [[SUBROUTINE_TYPE:![0-9]*]],
> {{.*}}, metadata [[FUNC_DECL:![0-9]*]], metadata {{![0-9]*}}} ; [
> DW_TAG_subprogram ] {{.*}} [def] [func]
> +// CHECK: [[SUBROUTINE_TYPE]] = {{.*}}, metadata [[TYPE_LIST:![0-9]*]],
> +// CHECK: [[TYPE_LIST]] = metadata !{metadata [[INT:![0-9]*]]}
> +// CHECK: [[INT]] = {{.*}} ; [ DW_TAG_base_type ] [int]
> +// CHECK: [[FUNC_DECL]] = {{.*}}, metadata !"_ZTS3foo", metadata
> [[SUBROUTINE_TYPE]], {{.*}}} ; [ DW_TAG_subprogram ] {{.*}} [func]
>
> struct foo {
> - auto func(); // CHECK: error: debug information for auto is not yet
> supported
> + static auto func();
> };
>
> foo f;
> +
> +auto foo::func() {
> + return 1;
> +}
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu<mailto:cfe-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141112/463cb5bb/attachment.html>
More information about the cfe-commits
mailing list