[dragonegg PATCH] Fix debug info for std::nullptr_t

[David Blaikie]

On Mon, Jul 1, 2013 at 2:03 PM, Greg Clayton <gclayton at apple.com> wrote:
>
> On Jun 26, 2013, at 2:38 PM, Eric Christopher <echristo at gmail.com> wrote:
>
>>>>
>>>> The short answer is that DW_TAG_unspecified_type can be used for more
>>>> than just nullptr_t.
>>>
>>> So shouldn't the function be called createUnspecifiedType (possibly
>>> with a createNullPtrType convenience function)?
>>>
>>
>> Yep. Feel free to make this change. (Don't worry about
>> createNullPtrType unless you really want it).
>>
>>>> The long answer is:
>>>>
>>>> "An unspecified (implicit, unknown, ambiguous or nonexistent) type is
>>>> represented by a debugging information entry with the tag
>>>> DW_TAG_unspecified_type. If a name has been given to the type, then
>>>> the corresponding unspecified type entry has a DW_AT_name attribute
>>>> whose value is a null-terminated string containing the name as it
>>>> appears in the source program. The interpretation of this debugging
>>>> information entry is intentionally left flexible to allow it to be
>>>> interpreted appropriately in different languages. For example, in C
>>>> and C++ the language implementation can provide an unspecified type
>>>> entry with the name “void” which can be referenced by the type
>>>> attribute of pointer types and typedef declarations for 'void' (see
>>>> Sections 0 and 5.3, respectively). As another example, in Ada such an
>>>> unspecified type entry can be referred to by the type attribute of an
>>>> access type where the denoted type is incomplete (the name is declared
>>>> as a type but the definition is deferred to a separate compilation
>>>> unit)."
>>>
>>> So the name is left unspecified.  Unsurprisingly, Clang and GCC have
>>> diverged here -- Clang uses "nullptr_t" as the name while GCC uses
>>> "decltype(nullptr)".  A standards proposal of sorts [1] proposes that
>>> "decltype(nullptr)" be used.  And it looks like LLDB only recognises
>>> the "nullptr_t" name [2].  What a mess.  Would changing Clang (and
>>> DragonEgg) to use "decltype(nullptr)", and making LLDB recognise it
>>> as well, present too many compatibility issues?
>>>
>>
>> Sounds good to me.
>>
>> Greg: Would you mind handling this on the LLDB end please?
>>
> % svn diff
> Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
> ===================================================================
> --- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (revision 185381)
> +++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (working copy)
> @@ -5740,7 +5740,8 @@
>                          break;
>
>                      case DW_TAG_unspecified_type:
> -                        if (strcmp(type_name_cstr, "nullptr_t") == 0)
> +                        if (strcmp(type_name_cstr, "nullptr_t") == 0 ||
> +                            strcmp(type_name_cstr, "decltype(nullptr)") == 0 )

Sounds good.

(though a little surprised you're dealing with raw c strings here,
rather than at least StringRef or somesuch)

>                          {
>                              resolve_state = Type::eResolveStateFull;
>                              clang_type = ast.getASTContext()->NullPtrTy.getAsOpaquePtr();
> % svn commit
> Sending        source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
> Transmitting file data .
> Committed revision 185382.
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits