<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 4, 2018 at 12:33 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span class=""><blockquote type="cite"><div>On Mar 3, 2018, at 11:30 PM, Daniel Berlin via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_7178844530764582925Apple-interchange-newline"><div><div dir="ltr">To explain to others who didn't follow that thread:<div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div></span>Glorious. :)</div><div><br></div></div></blockquote><div>I regretted it pretty much the second it was done :)</div><div><br></div><div>(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).</div><div><br></div><div>You can imagine what happens - demangler differences between host and target, compilers, etc, of course, will cause failure here.</div><div>It's also the case that the demangled name may not be the symbol as known in DWARF, etc.</div><div><br></div><div>One of the issues here is the demangling difference between binary and runtime, where, one produced Foo<2u> and one produced Foo<2></div><div><br></div><div>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.</div><div><br></div><div>(There are a bunch of open gdb bugs on differences like the above)</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div>Do any of the common C++ demangler implementations provide any sort of API to get at the demangler tree?</div></div></blockquote><div><br></div><div>Not that i know of :(</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>  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.</div><div><br></div></div></blockquote><div><br></div><div>Yeah, it definitely would be. </div><div><br></div><div>Most of what you see to support C++ in GDB are hacks, of course, from overload resolution to you name it.</div><div>:(</div><div><br></div></div></div></div>