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]

>
>
>
> >
> > - 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?
>
> It is being built with debug info, but type inspection happens on the
> debug info from each file on its own and there are many tools beyond LLDB
> that don't know how to locate symbols for other files. The other problem is
> you don't know what executable contains the full definition for this type.
> Kexts are like kernel shared libraries without an explicit executable
> dependency list (there is nothing in a kext that points to IOKit). User
> shared libraries have dependency lists that might be able to point to other
> executables, but not the kernel.
>

I'm guessing then there's an implicit list that could be/is hardcoded...

> 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).
>
> But this would only work for C++ classes that are virtual. For non-virtual
> base classes, we would have a tough time finding the one true full class
> definition.


This wouldn't trigger for non-virtual bases. It triggers for things with
vtables only.


> We would have to start pulling in all debug info for all shared libraries
> until we found it, which is not a great solution.
>

This would be true of any declaration - not just bases. Even without this
optimization you would need to have this support because you can have debug
info with only a forward declaration in it.


>
> >
> > If it can’t layout the type, the expression evaluator doesn’t work.
>
> LLDB can actually deal with the type missing because we assist clang in
> laying out the type using the information that is in the DWARF. Since we
> translate DWARF back into AST types, we need to do assisted layout because
> DWARF doesn't encode any packing attributes, or alignment attributes.
>
> >
> > 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).
>
> We can fix LLDB but at what cost? If we don't know where a "foo" base
> class comes from, should we start download _all_ debug info for _all_
> shared libraries until we find it? I don't really like that solution. I
> would like to see the full base class should always be there and would
> rather not have to use "-fno-limit-debug-info" which would make the debug
> info really really really bloated.
>

Really really bloated?

a) -flimit-debug-info is a more aggressive optimization than the vtable
optimization - it will cause many pointer uses to emit only declarations
and not definitions in the debug info. (it was even more aggressive before
I fixed it 3 months ago - if you were using -flimit-debug-info prior to
that then you're already far more tolerant to missing definitions than you
realize)

b) -flimit-debug-info is worth, at a guess, somewhere between 1 and 5%.
This vtable optimization is worth closer to 20%. That's /serious/ bloat to
consider accepting.


>
> I believe the optimization will work very well when all types are in the
> same shared library, but saying that all tools that want type information
> need to go and download and find debug info for any base class types
> manually is a bit too optimized for my taste. So the optimization has great
> potential when opted into, but I would rather not see it be the default.
>
> >
> > - David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131217/3e1e5e03/attachment.html>