On Dec 16, 2013, at 14:55, 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 this sentence is cut off in the middle :-) But extrapolating from that: For (LTO) builds we still have type uniquing which gets us the same kind of improvement and more. > > - 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?) Currently I believe that -flimit-debug-info is the default on Darwin. I don’t know what you mean by “these scenarios”; “we" can’t anticipate what programs users may want to probe using dtrace. > > - 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? Of course — by not performing this optimization, the type info for the base class ends up in the user’s .o file, as it always used to. This is just one example to make the "user code that inherits from base classes defined in 3rd-party C++ library” scenario I mentioned yesterday more real. > > - 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? 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). > > If it can’t layout the type, the expression evaluator doesn’t work. > > 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). I think Greg commented on the LLDB side of things already. -- adrian _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
