<div dir="ltr"><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"><br>
<div class="im"><br>
><br>
> - Kernel extensions tend to inherit from base classes that are defined in a system framework (I/O Kit works this way for example).<br>
><br>
> And the library where the base class is defined isn't built with debug info as a matter of course? Is that solvable at all?<br>
<br>
</div>It is being built with debug info, but type inspection happens on the debug info from each file on its own and there are many tools beyond LLDB that don't know how to locate symbols for other files. The other problem is you don't know what executable contains the full definition for this type. Kexts are like kernel shared libraries without an explicit executable dependency list (there is nothing in a kext that points to IOKit). User shared libraries have dependency lists that might be able to point to other executables, but not the kernel.<br>
</blockquote><div><br></div><div>I'm guessing then there's an implicit list that could be/is hardcoded... </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> I'm only vaguely familiar with such an idea and didn't realize you could get from the symbol back to the object file and thus to the dsym).<br>
<br>
</div>But this would only work for C++ classes that are virtual. For non-virtual base classes, we would have a tough time finding the one true full class definition. </blockquote><div><br></div><div>This wouldn't trigger for non-virtual bases. It triggers for things with vtables only.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We would have to start pulling in all debug info for all shared libraries until we found it, which is not a great solution.<br>
</blockquote><div><br></div><div>This would be true of any declaration - not just bases. Even without this optimization you would need to have this support because you can have debug info with only a forward declaration in it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> If it can’t layout the type, the expression evaluator doesn’t work.<br>
<br>
</div>LLDB can actually deal with the type missing because we assist clang in laying out the type using the information that is in the DWARF. Since we translate DWARF back into AST types, we need to do assisted layout because DWARF doesn't encode any packing attributes, or alignment attributes.<br>

<div class="im"><br>
><br>
> We do need to have the option to turn this optimization off; preferably we would make off the default for Darwin. Other platforms that use LLDB as their primary debugger may want to do the same thing.<br>
><br>
> Is there no way to fix LLDB so it actually loads in the other dsyms and finds the full definition of the type? It would seem unfortunate to have such a bloated debug info format (not only for this optimization, but for the existing -flimit-debug-info optimizations and anything else we might think of in the future where we can ensure that some debug info is already availabel in another file).<br>

<br>
</div>We can fix LLDB but at what cost? If we don't know where a "foo" base class comes from, should we start download _all_ debug info for _all_ shared libraries until we find it? I don't really like that solution. I would like to see the full base class should always be there and would rather not have to use "-fno-limit-debug-info" which would make the debug info really really really bloated.<br>
</blockquote><div><br></div><div>Really really bloated? <br><br>a) -flimit-debug-info is a more aggressive optimization than the vtable optimization - it will cause many pointer uses to emit only declarations and not definitions in the debug info. (it was even more aggressive before I fixed it 3 months ago - if you were using -flimit-debug-info prior to that then you're already far more tolerant to missing definitions than you realize)<br>
<br>b) -flimit-debug-info is worth, at a guess, somewhere between 1 and 5%. This vtable optimization is worth closer to 20%. That's /serious/ bloat to consider accepting.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
I believe the optimization will work very well when all types are in the same shared library, but saying that all tools that want type information need to go and download and find debug info for any base class types manually is a bit too optimized for my taste. So the optimization has great potential when opted into, but I would rather not see it be the default.<br>

<br>
><br>
> - David<br>
<br>
</blockquote></div><br></div></div>