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

[Eric Christopher]

On Wed, Jun 26, 2013 at 2:42 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 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)
>

True, we don't. Might want to I guess.

-eric

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