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]

Let's see if I've managed to divine the use case that you're talking about
here so we can attempt to refocus the discussion somewhat:

a) You ship headers and libraries to customers.
b) You will not or, at least, have not shipped debug info to those
customers.
c) For this case in particular:
   1) The headers contain a polymorphic base class
   2) Customers derive from this polymorphic base class
   3) Linking still works since the customer has the library but not the
debug info for the base class where the key function was emitted.

Is this correct?

-eric

On Tue Dec 17 2013 at 2:31:12 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Tue, Dec 17, 2013 at 12:23 PM, Greg Clayton <gclayton at apple.com> wrote:
>
> >
> > >
> > > 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)
>
> I was saying that using "-fno-limit-debug-info" should not try to cull
> _any_ debug info and would result in all types being emitted with complete
> definitions, no?
>
>
> No - what you're describing is GCC's -gfull, which Clang does not
> currently implement.
>
> Here's the way things are:
>
> Clang never emits types that are not referenced from some codegen'd
> costruct. That means an inline function with no callers has no debug info
> (& thus any types it uses (parameters, local variables, etc)aren't placed
> in the debug info), for example. Any type that /is/ referenced by a
> codegen'd construct will be emitted as a declaration if that's all that is
> available in this translation unit, or a definition if one is provided
> (even if the definition is provided after the use: struct foo; foo *f;
> struct foo { }; )
>
> -flimit-debug-info (the default) goes a step further than that - it
> doesn't emit definitions, even if they're available in the source, if the
> type is not used in such a way that the definition is required (using
> Clang's "required to be complete" callback). So the above 'foo' example
> would not produce a definition of 'foo', but this example would: "struct
> foo; foo *f; struct foo { int i; }; void func() { i->i = 3; }"). The
> assumption being that if the type is never dereferenced in this translation
> unit the definition is not required and we can rely on the definition being
> provided in whatever other translation unit actually does the
> dereferencing. This feature was specifically requested/suggested by Chris
> Lattner, as far as I'm aware. When Eric measured the first implementation
> of this I think he recorded only a 2-3% savings. Since my improvements to
> this we haven't done any size comparisons, so I'm not sure what it's worth.
>
> The vtable optimization, like the limit-debug-info approach, uses a
> similar (though stronger - because it relies on a language guarantee not
> just an informal heuristic) approach to guarantee that some other
> translation unit will contain the debug info for the type.
>
>
>
> >
> > 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 don't consider bloat being something that helps us to completely define
> a type that is going to be use when debugging so we can show the entire
> type and its member variables to the user.
>
>
> How do you know which types are going to be needed by the user? What about
> types that are only declared but not defined in this translation unit?
> ("struct foo; foo *f;")
>
>
> Also to be able to call functions on the base class is helpful too for
> people evaluating expressions. So I do realize you guys consider this
> bloat, but this information to us is important for the debug info to be
> useful.
>
>
> My suggestion is that if you cannot rely on other parts of the project to
> be built with debug info then you are going to have some /very/ expensive
> intermediate debug info. This is simply a warning - I can't stop you from
> making that choice, but it seems to go against a lot of efforts you, us,
> and everyone have been making to improve the quality (including the size)
> of debug info.
>
> & I'm still rather confused as to how this could be the correct general
> approach because there will always be cases where one translation unit only
> has access to a declaration of a type ("struct foo; foo *f;") - you must be
> able to go looking for the definition of that type for many use cases.
>
>
> - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131218/0cbade96/attachment.html>