[lldb-dev] How to deal with STL type names in C++ code?

Thu Aug 6 15:58:25 PDT 2015

> On Aug 6, 2015, at 3:50 PM, Siva Chandra <sivachandra at google.com> wrote:
> 
> 
> 
> On Thu, Aug 6, 2015 at 3:38 PM, Enrico Granata <egranata at apple.com <mailto:egranata at apple.com>> wrote:
> 
>> On Aug 6, 2015, at 3:33 PM, Siva Chandra <sivachandra at google.com <mailto:sivachandra at google.com>> wrote:
>> 
>> 
>> 
>> On Thu, Aug 6, 2015 at 2:43 PM, Enrico Granata <egranata at apple.com <mailto:egranata at apple.com>> wrote:
>> To be honest, my favorite approach would be to modify clang’s TypePrinter to do this, and then hooking up GetDisplayTypeName() to use whatever flags would be necessary to invoke that bit of magic
>> 
>> Do you mean that clang's "pretty printer" should be made extensible by a script?
>>  
> 
> Nope, what I am imagining is not an extensible system
> 
> When LLDB goes to print a type it asks the compiler “what is the name of this type that I should display?”
> By default, clang prints the fully specialized template, including type arguments that have their default value. My theory is that we would want to add a mode to the type printer to say “simplify type name”, and that would do sensible things to get a display name that is more compact
> 
> So, how would clang know about the "simplified" or "friendly" name for a type? Even in case of standard library types, the underlying types (with unfriendly type names) could be anything. For example, libstdc++ and STLport have different underlying naming conventions. So does libc++ I would imagine (I have not spent enough time yet staring at libc++ code).
> 

The obvious mechanism is that the compiler has knowledge of the structure of the type - so it can make printing decisions based on that type structure
In this case, I imagine a viable approach would be having rules like omitting the values of template arguments that have a default value, omit inlined namespaces, ...

> 
> That seems more interesting than a set of regular expression heuristics on the type name, which is probably all you could do without specialized compiler-y knowledge of types 
> 
>> 
>>> On Aug 6, 2015, at 2:33 PM, Siva Chandra <sivachandra at google.com <mailto:sivachandra at google.com>> wrote:
>>> 
>>> FWIW, GDB has a similar concept called type-printers:
>>> https://sourceware.org/gdb/current/onlinedocs/gdb/Type-Printing-API.html <https://sourceware.org/gdb/current/onlinedocs/gdb/Type-Printing-API.html>
>>> 
>>> On Thu, Aug 6, 2015 at 2:24 PM, Siva Chandra <sivachandra at google.com <mailto:sivachandra at google.com>> wrote:
>>>> Hi Enrico,
>>>> 
>>>> I was thinking about the same issue today. Could we add a concept
>>>> called "TypeNameModifier" and provide ability to define modifiers in
>>>> scripts and command line? With this, a name like
>>>> std::__1::basic_string<...> can be modified into a more friendly name
>>>> like std::string? We could ofcourse have more complex modifications.
>>>> 
>>>> I think it is doable, but what is your (and the community's) opinion
>>>> about adding such a feature? If you are OK, I would like to take up
>>>> adding such a feature.
>>>> 
>>>> Thanks,
>>>> Siva Chandra
>>>> 
>>>> On Thu, Aug 6, 2015 at 2:15 PM, Enrico Granata via lldb-dev
>>>> <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>>>> Hi Eugene,
>>>>> 
>>>>> On Aug 6, 2015, at 2:02 PM, Eugene Birukov via lldb-dev
>>>>> <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I am using LLDB C++ API to create custom debugger and trying to dump
>>>>> variables with their types. To do that I am using SBValue.GetTypeName() API.
>>>>> Some types are OK, but some others - especially ones related to STL - are
>>>>> quite unreadable:
>>>>> 
>>>>> 
>>>>> those type names are the actual fully-specialized STL type names. I am not
>>>>> sure how to control GDB to stop truncating your string formatting, but after
>>>>> the “…” there actually is more text
>>>>> It looks like what you have is std::unique_ptr<std::vector<std::string> > >
>>>>> and those templates all take more arguments which are defaulted so you don’t
>>>>> have to type them in code - but are reflected in the type name
>>>>> 
>>>>> (gdb) p value.GetTypeName()
>>>>> $1 = 0x7fffe419be40
>>>>> "std::__1::unique_ptr<std::__1::vector<std::__1::basic_string<char,
>>>>> std::__1::char_traits<char>, std::__1::allocator<char> >,
>>>>> std::__1::allocator<std::__1::basic_string<char,
>>>>> std::__1::char_traits<char"...
>>>>> (gdb) p value.GetDisplayTypeName()
>>>>> $2 = 0x7fffe419be40
>>>>> "std::__1::unique_ptr<std::__1::vector<std::__1::basic_string<char,
>>>>> std::__1::char_traits<char>, std::__1::allocator<char> >,
>>>>> std::__1::allocator<std::__1::basic_string<char,
>>>>> std::__1::char_traits<char"...
>>>>> (gdb)
>>>>> 
>>>>> 
>>>>> So, is there any way to convert them into some more human-friendly form?
>>>>> 
>>>>> 
>>>>> Not currently. What one would have to do is hook into the C++ type printing
>>>>> logic such that it would know to leave out these extra template arguments
>>>>> when they have a default value
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Eugene
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> - Enrico
>>>>> 📩 egranata@.com ️ 27683
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>>>> 
>> 
>> 
>> Thanks,
>> - Enrico
>> 📩 egranata@.com ☎️ 27683
>> 
>> 
> 
> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150806/3d3af70a/attachment-0001.html>