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

[John McCall via cfe-dev]

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