> > > > > > > - Kernel extensions tend to inherit from base classes that are defined > in a system framework (I/O Kit works this way for example). > > > > 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? > > 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. >
I'm guessing then there's an implicit list that could be/is hardcoded... > 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). > > 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. This wouldn't trigger for non-virtual bases. It triggers for things with vtables only. > We would have to start pulling in all debug info for all shared libraries > until we found it, which is not a great solution. > 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. > > > > > If it can’t layout the type, the expression evaluator doesn’t work. > > 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. > > > > > 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. > > > > 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). > > 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. > Really really bloated? 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) 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. > > 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. > > > > > - David > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
