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

[David Blaikie]

On Wed, Jun 26, 2013 at 2:35 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> On Wed, Jun 26, 2013 at 01:48:21PM -0700, Eric Christopher wrote:
>> On Wed, Jun 26, 2013 at 1:34 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>> > On Wed, Jun 26, 2013 at 07:29:36PM +0200, Duncan Sands wrote:
>> >> Hi Peter,
>> >>
>> >> On 26/06/13 01:59, Peter Collingbourne wrote:
>> >>> On Tue, Jun 25, 2013 at 04:57:38PM -0700, Peter Collingbourne wrote:
>> >>>> Hi,
>> >>>>
>> >>>> This fixes debug info emission for std::nullptr_t (previously it would crash).
>> >>>>
>> >>>> OK to commit?
>> >>>
>> >>> With patch this time.
>> >>
>> >> thanks.  How about getting the name from the type rather than assuming it is
>> >> nullptr_t?
>> >
>> > I don't think it's possible for the debug info for nullptr_t to
>> > be of any form other than a DW_TAG_unspecified_type with a name of
>> > "nullptr_t" -- at least there doesn't seem to be a way to get Clang
>> > to spit out something else.  (For that matter, it isn't clear to me
>> > why DIBuilder::createNullPtrType lets you specify the name.)  Eric?
>> >
>>
>> 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)?
>
>> 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.

The proposal (which isn't proposing anything) merely states that "the
type of nullptr is decltype(nullptr)" which is true but incomplete,
the C++ standard states "The pointer literal is the keyword nullptr.
It is a prvalue of type std::nullptr_t." (though I'll admit we
probably don't put the nullptr_t type in the std namespace)

> 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?
>
> Thanks,
> --
> Peter
>
> [1] http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Null_pointer
> [2] https://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp?revision=184388&view=markup#l5741
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits