On Dec 16, 2013, at 2:55 PM, David Blaikie <[email protected]> wrote:
> > > > On Mon, Dec 16, 2013 at 2:44 PM, Adrian Prantl <[email protected]> wrote: > Hi Chandler and David, > > unfortunately it looks more like case 1. This optimization breaks several > assumptions that tools in our software stack depend on. > > It's a fairly substantial debug info size savings that seems worth > investigating whether you can keep it enabled at least in > > - For example, it breaks dtrace, which on Darwin relies on being able to pull > the (complete) CTF info (compact C type format) out of the DWARF in the .dSYM > for a given module. > > I take it you're already using -fno-limit-debug-info for these scenarios, > then? (are you using -flimit-debug-info at all?) Yes, this is what will need to happen now that clang has changed. > > - 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. > > - For LLDB it is not always possible to tell where a type came from and > vtable symbols can get stripped from the symbol table. > > I don't understand the relevance of vtable stripping to this issue - could > you explain it to me? (are you suggesting that the vtable symbol lookup > could/would be used to locate the right object file/dsym to load the full > definition of the type? Yes, find the vtable symbol, find the file and debug info that contains the real definition of the type is the idea. > 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. We would have to start pulling in all debug info for all shared libraries until we found it, which is not a great solution. > > 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. 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
