[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