<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 4, 2018, at 10:20 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" class="">dberlin@dberlin.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Mar 4, 2018 at 12:33 AM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><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" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Mar 3, 2018, at 11:30 PM, Daniel Berlin via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_7178844530764582925Apple-interchange-newline"><div class=""><div dir="ltr" class="">To explain to others who didn't follow that thread:<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div></span>Glorious. :)</div><div class=""><br class=""></div></div></blockquote><div class="">I regretted it pretty much the second it was done :)</div><div class=""><br class=""></div><div class="">(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 class=""><br class=""></div><div class="">You can imagine what happens - demangler differences between host and target, compilers, etc, of course, will cause failure here.</div><div class="">It's also the case that the demangled name may not be the symbol as known in DWARF, etc.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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></div></div></div></blockquote><div><br class=""></div>Yeah, having debug info associated with the v-table object that links to the type information would be pretty sensible.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">(There are a bunch of open gdb bugs on differences like the above)</div><div class=""><br class=""></div><div class=""> <br class=""></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" class=""><div class=""></div><div class="">Do any of the common C++ demangler implementations provide any sort of API to get at the demangler tree?</div></div></blockquote><div class=""><br class=""></div><div class="">Not that i know of :(</div></div></div></div></div></blockquote><div><br class=""></div>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?)</div><div> </div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><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" class=""><div class=""> 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 class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah, it definitely would be. </div><div class=""><br class=""></div><div class="">Most of what you see to support C++ in GDB are hacks, of course, from overload resolution to you name it.</div><div class="">:(</div></div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>John.</div><br class=""></body></html>