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

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.

If you don't emit the linkage name, there are cases it won't find it,
because this is a really dumb way of trying to find the answer :)

It also wont' find it depending on what demangler you use, etc.

Here's a more direct way:
For each vtable DIE, link to the concrete type it represents.

Now you just go from vtable object to concrete type with no string lookup,
which is faster, doesnt' require linkage names, doesn't depend on
demanglers matching, etc.

As an added bonus: This is what Tom Tromey already added to Rust to do
this. So it's even been implemented before.






On Sat, Mar 3, 2018 at 8:20 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
>
>
> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> As you may know modern C++ debuggers (GDB and LLDB) support dynamic
type
>> identification for polymorphic objects, by utilizing C++ RTTI.
>> Unfortunately this feature does not work with Clang and GDB >= 7.x .
The
>> last compiler that worked well was G++ 6.x
>>
>> I've asked about this issue both on GDB and LLDB maillists.
Unfortunately
>> it's hard or impossible to fix it on debugger side.
>>
>
> Errr, i posited a solution on the gdb mailing list that i haven't seen
> shot down so far, that doesn't require linkage names, it only requires
one
> new attribute that is a DW_FORM_ref, and very cheap.
>
> I also wrote the RTTI code for GDB :)
>
> Currently what debugger has to do is to demangle RTTI name and try to
>> match it to DW_AT_name attribute to find type. As you can see it does
not
>> work for any of 3 examples.
>>
>> I've asked about the problem on G++ maillist, and one of the
proposed
>> solutions is to emit DW_AT_linkage_name for types.
>>
>> Can this solution be also implemented in LLVM?
>>
>
> Please, no.
>
> This is completely unneeded and wastes a huge amount of space.
>
> As you can see from the replies to my solution on the gdb mailing list, it
> is used by other languages (rust, for example) *anyway*, so we might as
> well use it for C++ too.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180303/8971a555/attachment.html>

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

Do any of the common C++ demangler implementations provide any sort of API to
get at the demangler tree?  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.

John.
> 
> If you don't emit the linkage name, there are cases it won't find
it, because this is a really dumb way of trying to find the answer :)
> 
> It also wont' find it depending on what demangler you use, etc.
> 
> Here's a more direct way:
> For each vtable DIE, link to the concrete type it represents.
> 
> Now you just go from vtable object to concrete type with no string lookup,
which is faster, doesnt' require linkage names, doesn't depend on
demanglers matching, etc.
> 
> As an added bonus: This is what Tom Tromey already added to Rust to do
this. So it's even been implemented before.
> 
> 
> 
> 
> 
> 
> On Sat, Mar 3, 2018 at 8:20 PM, Daniel Berlin <dberlin at dberlin.org
<mailto:dberlin at dberlin.org>> wrote:
> 
> 
> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi all,
> 
> As you may know modern C++ debuggers (GDB and LLDB) support dynamic type
identification for polymorphic objects, by utilizing C++ RTTI.
> Unfortunately this feature does not work with Clang and GDB >= 7.x . 
The last compiler that worked well was G++ 6.x
> 
> I've asked about this issue both on GDB and LLDB maillists.
Unfortunately it's hard or impossible to fix it on debugger side.
> 
> Errr, i posited a solution on the gdb mailing list that i haven't seen
shot down so far, that doesn't require linkage names, it only requires one
new attribute that is a DW_FORM_ref, and very cheap.
>  
> I also wrote the RTTI code for GDB :)
> 
> Currently what debugger has to do is to demangle RTTI name and try to match
it to DW_AT_name attribute to find type. As you can see it does not work for any
of 3 examples.
> 
> I've asked about the problem on G++ maillist, and one of the proposed
solutions is to emit DW_AT_linkage_name for types.
> 
> Can this solution be also implemented in LLVM? 
> 
> Please, no.
> 
> This is completely unneeded and wastes a huge amount of space.
> 
> As you can see from the replies to my solution on the gdb mailing list, it
is used by other languages (rust, for example) *anyway*, so we might as well use
it for C++ too.
> 
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180304/4542c544/attachment.html>

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>