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

Eric Christopher echristo at gmail.com
Wed Jun 26 14:38:25 PDT 2013


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

-eric




More information about the llvm-commits mailing list