<p dir="ltr"><br>
On Jul 1, 2013 6:30 PM, "Greg Clayton" <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
><br>
><br>
> On Jul 1, 2013, at 2:13 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
> > On Mon, Jul 1, 2013 at 2:03 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
> >><br>
> >> On Jun 26, 2013, at 2:38 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
> >><br>
> >>>>><br>
> >>>>> The short answer is that DW_TAG_unspecified_type can be used for more<br>
> >>>>> than just nullptr_t.<br>
> >>>><br>
> >>>> So shouldn't the function be called createUnspecifiedType (possibly<br>
> >>>> with a createNullPtrType convenience function)?<br>
> >>>><br>
> >>><br>
> >>> Yep. Feel free to make this change. (Don't worry about<br>
> >>> createNullPtrType unless you really want it).<br>
> >>><br>
> >>>>> The long answer is:<br>
> >>>>><br>
> >>>>> "An unspecified (implicit, unknown, ambiguous or nonexistent) type is<br>
> >>>>> represented by a debugging information entry with the tag<br>
> >>>>> DW_TAG_unspecified_type. If a name has been given to the type, then<br>
> >>>>> the corresponding unspecified type entry has a DW_AT_name attribute<br>
> >>>>> whose value is a null-terminated string containing the name as it<br>
> >>>>> appears in the source program. The interpretation of this debugging<br>
> >>>>> information entry is intentionally left flexible to allow it to be<br>
> >>>>> interpreted appropriately in different languages. For example, in C<br>
> >>>>> and C++ the language implementation can provide an unspecified type<br>
> >>>>> entry with the name “void” which can be referenced by the type<br>
> >>>>> attribute of pointer types and typedef declarations for 'void' (see<br>
> >>>>> Sections 0 and 5.3, respectively). As another example, in Ada such an<br>
> >>>>> unspecified type entry can be referred to by the type attribute of an<br>
> >>>>> access type where the denoted type is incomplete (the name is declared<br>
> >>>>> as a type but the definition is deferred to a separate compilation<br>
> >>>>> unit)."<br>
> >>>><br>
> >>>> So the name is left unspecified. Unsurprisingly, Clang and GCC have<br>
> >>>> diverged here -- Clang uses "nullptr_t" as the name while GCC uses<br>
> >>>> "decltype(nullptr)". A standards proposal of sorts [1] proposes that<br>
> >>>> "decltype(nullptr)" be used. And it looks like LLDB only recognises<br>
> >>>> the "nullptr_t" name [2]. What a mess. Would changing Clang (and<br>
> >>>> DragonEgg) to use "decltype(nullptr)", and making LLDB recognise it<br>
> >>>> as well, present too many compatibility issues?<br>
> >>>><br>
> >>><br>
> >>> Sounds good to me.<br>
> >>><br>
> >>> Greg: Would you mind handling this on the LLDB end please?<br>
> >>><br>
> >> % svn diff<br>
> >> Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp<br>
> >> ===================================================================<br>
> >> --- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (revision 185381)<br>
> >> +++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (working copy)<br>
> >> @@ -5740,7 +5740,8 @@<br>
> >> break;<br>
> >><br>
> >> case DW_TAG_unspecified_type:<br>
> >> - if (strcmp(type_name_cstr, "nullptr_t") == 0)<br>
> >> + if (strcmp(type_name_cstr, "nullptr_t") == 0 ||<br>
> >> + strcmp(type_name_cstr, "decltype(nullptr)") == 0 )<br>
> ><br>
> > Sounds good.<br>
> ><br>
> > (though a little surprised you're dealing with raw c strings here,<br>
> > rather than at least StringRef or somesuch)<br>
><br>
><br>
> The strings are from the .debug_str in DWARF. We tend not to StringRef all strings in the DWARF string table because of the space that would require (pointer + size_t).<br>
><br>
> For higher performance we can switch to lldb_private::ConstString which puts and uniques strings in a constant string pool, but then we pay the cost of hashing and getting the unique string just to do the compare. C++ tends to make very very very large string pools out of the DWARF .debug_str and we really can't afford the extra space for StringRef permanent storage. Nor do we want every string table access to the .debug_str to incur the cost of calling strlen() for every string each time we access it.<br>
><br>
> Rest assured if these areas ever show up as performance issues we will take care of the issues.</p>
<p dir="ltr">The specific issue that springs to mind here is that strcmp is sort of inefficient for equality if you happen to know the length already. If that's never/not often the case here then that's a non-issue.</p>
<p dir="ltr">><br>
> Greg<br>
><br>
</p>