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


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


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


> - For LLDB it is not always possible to tell where a type came from and
> vtable symbols can get stripped from the symbol table.


I don't understand the relevance of vtable stripping to this issue - could
you explain it to me? (are you suggesting that the vtable symbol lookup
could/would be used to locate the right object file/dsym to load the full
definition of the type? 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).


> If it can’t layout the type, the expression evaluator doesn’t work.
>
> 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).

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