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

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

I think Greg commented on the LLDB side of things already.

-- adrian