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

Peter Collingbourne peter at pcc.me.uk
Wed Jun 26 14:35:14 PDT 2013


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



More information about the llvm-commits mailing list