<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 5, 2018 at 8:37 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>As you may know modern C++ debuggers (GDB and LLDB) support dynamic type identification for polymorphic objects, by utilizing C++ RTTI.  </div><div>Unfortunately this feature does not work with Clang and GDB >= 7.x .  The last compiler that worked well was G++ 6.x</div><div><br></div><div>I've asked about this issue both on GDB and LLDB maillists. Unfortunately it's hard or impossible to fix it on debugger side.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote></span><div><br>FWIW, for C++ at least, neither Clang nor GCC (6.3) produce any DWARF to describe the vtable itself (they describe the vtable pointer inside the struct, but not the constant vtable array) - so it'll be a bit more than one attribute, but the bytes describe the vtable (as a global variable? Do we give it a name? (if so, we're back to paying that cost)) first, then to add the reference from that to the type.<br></div></div></div></blockquote><div><br></div><div>Right, they produce a named symbol but not debug info.</div><div><br></div><div>The only thing you need is a single DIE for that symbol, with a single ref.</div><div><br></div><div>(IE they just need to be able to say "find me the DIE for this address range", have it get to the vtable DIE, and get to the concrete type die)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br>& I'm not sure what Apple would do or anyone else that has libraries without debug info shipped & users have to debug them (this is what broke -fno-standalone-debug for Apple - their driver API which ships without debug info of its own, has strong vtables in it).<br></div></div></div></blockquote><div><br></div><div>I'm confused.</div><div>This already seems to have  has the same issue?<br>Just because it uses one linker symbol, it still requires full debug info to print the type anyway.</div><div>So if it's gone, nothing changes. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br>I can go into more detail there - but there are certainly some annoying edge cases/questions I have here :/</div></div></div></blockquote><div><br></div><div>Constructive alternative?<br><br></div><div>Right now, relying on *more* names, besides being huge in a lot of binaries,  relies on the demangler producing certain text (which is not guaranteed)<br></div><div>That text has to exactly match the text of some other symbol (which is not guaranteed).</div><div><br></div><div>That 10 second delay you get sometimes with going to print a C++ symbol in a large binary?<br><br></div><div>That's this lookup.</div><div><br></div><div>So right now it:<br>1. Uses a ton of memory</div><div>2. Uses a ton of time</div><div>3. Doesn't work all the time (depends on demanglers, and there are very weird edge cases here).</div><div><br></div><div>Adding linkage names will not change any of these, whereas adding a DWARF extension fixes all three, forever.</div><div><br></div><div>I don't even care about the details of the extension, my overriding constraint is "please don't extend this hack further given the above".</div><div><br></div></div></div></div>