llvm dev - Mar 2018 - [cfe-dev] Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

On Sun, Mar 4, 2018 at 12:33 AM, John McCall <rjmccall at apple.com>
wrote:
> On Mar 3, 2018, at 11:30 PM, Daniel Berlin via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> To explain to others who didn't follow that thread:
>
> GDB currently does something amazingly stupid (and has since i wrote it)
> to find the RTTI type.  There were no other good options at the type.
>
> What it does is find the vtable for the object, find the symbol that
> represents the vtable, demangle it, , chops off "vtable for", and
tries to
> find the symbol for the string that results.
>
>
> Glorious. :)
>
> I regretted it pretty much the second it was done :)
(but nothing else implemented the itanium C++ ABI yet, we still had to deal
with STABS, DBX, etc, so there wasn't a great way to push conformity here).

You can imagine what happens - demangler differences between host and
target, compilers, etc, of course, will cause failure here.
It's also the case that the demangled name may not be the symbol as known
in DWARF, etc.

One of the issues here is the demangling difference between binary and
runtime, where, one produced Foo<2u> and one produced Foo<2>

Personally, as is apparent, i don't think we should solve these by going
down the rabbit hole of "using more names", when it's pretty
trivial to
just link the things together and not have to do the lookup at all.

(There are a bunch of open gdb bugs on differences like the above)


> Do any of the common C++ demangler implementations provide any sort of API
> to get at the demangler tree?
>
Not that i know of :(

>  We did this in Swift, and even though our tree design isn't real
great,
> it's been a huge help for implementing various reflection / debugging
> features.
>
>
Yeah, it definitely would be.

Most of what you see to support C++ in GDB are hacks, of course, from
overload resolution to you name it.
:(
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180304/56ee5605/attachment.html>

> On Mar 4, 2018, at 10:20 AM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> 
> 
> 
> On Sun, Mar 4, 2018 at 12:33 AM, John McCall <rjmccall at apple.com
<mailto:rjmccall at apple.com>> wrote:
>> On Mar 3, 2018, at 11:30 PM, Daniel Berlin via cfe-dev <cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> 
>> To explain to others who didn't follow that thread:
>> 
>> GDB currently does something amazingly stupid (and has since i wrote
it) to find the RTTI type.  There were no other good options at the type.
>> 
>> What it does is find the vtable for the object, find the symbol that
represents the vtable, demangle it, , chops off "vtable for", and
tries to find the symbol for the string that results.
> 
> Glorious. :)
> 
> I regretted it pretty much the second it was done :)
> 
> (but nothing else implemented the itanium C++ ABI yet, we still had to deal
with STABS, DBX, etc, so there wasn't a great way to push conformity here).
> 
> You can imagine what happens - demangler differences between host and
target, compilers, etc, of course, will cause failure here.
> It's also the case that the demangled name may not be the symbol as
known in DWARF, etc.
> 
> One of the issues here is the demangling difference between binary and
runtime, where, one produced Foo<2u> and one produced Foo<2>
> 
> Personally, as is apparent, i don't think we should solve these by
going down the rabbit hole of "using more names", when it's pretty
trivial to just link the things together and not have to do the lookup at all.
Yeah, having debug info associated with the v-table object that links to the
type information would be pretty sensible.
> (There are a bunch of open gdb bugs on differences like the above)
> 
>  
> Do any of the common C++ demangler implementations provide any sort of API
to get at the demangler tree?
> 
> Not that i know of :(
Seems like a reasonable project!  Maybe we can get a SoC student to make a
standalone C++ demangler library with a tree API (an unstable one should be
fine), and debuggers can just use that instead of relying on the OS's
cxa_demangle.  (I'm really not sure why development tools rely on the system
demangler anyway; surely it's always easier to tell users that they'd
get a better experience with a new debugger than to tell them that they need to
replace their system's C++ standard library?)
 
>  We did this in Swift, and even though our tree design isn't real
great, it's been a huge help for implementing various reflection / debugging
features.
> 
> 
> Yeah, it definitely would be. 
> 
> Most of what you see to support C++ in GDB are hacks, of course, from
overload resolution to you name it.
> :(
Yeah.  LLDB's C++ support doesn't always work (grr argh templates), but
being able to rely on an actual compiler frontend is just a huge step forward
for making all the language features work right.

John.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180304/00f08b8b/attachment.html>

On Sun, 4 Mar 2018 at 20:33, John McCall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> Seems like a reasonable project!  Maybe we can get a SoC student to make a
> standalone C++ demangler library with a tree API (an unstable one should be
> fine), and debuggers can just use that instead of relying on the OS's
> cxa_demangle.  (I'm really not sure why development tools rely on the
> system demangler anyway; surely it's always easier to tell users that
> they'd get a better experience with a new debugger than to tell them
that
> they need to replace their system's C++ standard library?)
>
>
I believe there is some work being done on that already <
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013186.html>, but
I'm
not sure what's the current state of it. Also, in the default
configuration, LLDB will use lllvm::itaniumDemangle for demangling
(although there is a build option to use cxa_demangle).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/14f392aa/attachment.html>