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

[Eric Christopher]

>From the standard point of view it does appear that this trick is legal btw:

"A debugging information entry that represents a non-defining or otherwise
incomplete declaration of a program entity has a
DW_AT_declaration attribute, which is a flag..."

so this is merely being labeled as an incomplete type and is valid dwarf.

I'm not a fan of it necessarily, but a 20% win per object file is huge. I'd
honestly prefer that struct types worked more like namespaces, but that's a
rather serious change to the standard.

-eric

On Mon Dec 16 2013 at 4:44:25 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> 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
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131216/da24b006/attachment.html>