r188739 - Revert "Revert "Revert "Revert "DebugInfo: Omit debug info for dynamic classes in TUs that do not have the vtable for that class""""

David Blaikie dblaikie at gmail.com
Mon Dec 16 17:10:36 PST 2013


On Mon, Dec 16, 2013 at 4:42 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> On Dec 16, 2013, at 14:55, David Blaikie <dblaikie at gmail.com> wrote:
>
> >
> >
> >
> > On Mon, Dec 16, 2013 at 2:44 PM, Adrian Prantl <aprantl at apple.com>
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131216/54ce7b4f/attachment.html>


More information about the cfe-commits mailing list