On Mon, Dec 16, 2013 at 4:42 PM, Adrian Prantl <[email protected]> wrote:
> > 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. > Sure - in the final linked debug info, but you'll still suffer a disk/build-time penalty for all that & that only applies to LTO. I was trying to say "keep it enabled at least in some cases" - ie: look at the cases where you're having trouble with this optimization and see if a more targetted approach to addressing those particular use cases can be employed. > - 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. > Can dtrace be improved to read the rest of the debug info/can you ship debug info for the libraries in question? > > > > - 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. > I meant is it possible to solve the problem of "this library is built without debug info" - in my experience libraries generally offer a dbg variant of the library for this purpose. Is this a possible solution to your problem? Or are you unable to ship the libraries in question with appropriate debug info & must rely on the user's builds to contain sufficient info? (notice that I first discovered this GCC optimization looking at basic_ifstream - the stream base is polymorphic and has an out-of-line vtable - this optimization allows code using C++ streams to avoid emitting /tons/ of stream related debug info and rely on it being present in the debug build of the standard library)
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
