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]

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

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


Because the fact that this change caused a problem is a symptom, not
necessarily the underlying issue. Fixing/removing this change isn't
necessarily going to solve a broad class of problems your users will hit
again if you don't address the underlying problem.

If you're working with -flimit-debug-info by default you'll have other
problems (if you have an opaque pointer type, or otherwise handle it
without dereferencing it, Clang will emit a declaration and not a
definition - prior to my improvements to -flimit-debug-info this would even
fire in many more cases causing pointer uses to emit declarations and not
definitions (try T *x = new T() with 3.4) - these are issues your users
should already be being impacted by) due to the same root cause.

Many ways we have already and will continue to improve debug info size rely
on the presence of debug info for the whole program/libraries. Yes, these
include changes made by/for Apple dating back years. This isn't a new or
surprising thing.


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


This isn't new... it's common for code in one TU to have a declaration of a
type and another TU to have the definition (heck, if it wasn't possible -
we wouldn't have declarations in DWARF, we'd just have definitions).

I understand that your kernel situation is special and might not be built
to handle these common/practical issues - and should really be fixed but
that such fixing is entirely up to your timeline & even if it's a priority
it won't be something that can be addressed quickly.

I'm not opposed to a flag here, though understanding the right semantics
and use-cases for that flag seems important (& understanding what the costs
are too - but again, it's your platform, I can advise you but ultimately I
can't stop you choosing whatever you want as the defaults for your
platform).

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131217/7f120b83/attachment.html>