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

[Daniel Berlin via cfe-dev]

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/cfe-dev/attachments/20180304/56ee5605/attachment.html>