On Dec 17, 2013, at 14:29, David Blaikie <[email protected]> wrote:
> > > > On Tue, Dec 17, 2013 at 12:23 PM, Greg Clayton <[email protected]> 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. > I took the opportunity to document the effect of -flimit-debug-info in the man page. (CFE r197819). -- adrian _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
