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

[Adrian Prantl]

On Dec 16, 2013, at 5:10 PM, David Blaikie <dblaikie at gmail.com> wrote:

> >
> > - 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?

Is that even relevant to the problem? Before we had this change, the above scenario was possible, and users could debug the base class from the 3rd-party library. Now they can't. We should give them an option to make this work again.
> 
> (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)

Sure, if you can control the compiler flags for the entire software stack (and all your library vendors give you debug symbols) and your entire toolchain supports "distributed" DWARF, this works very well.

-- adrian