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 Jan 3, 2014, at 8:52, dblaikie at gmail.com wrote:
> > Are there any flags that control the debug info =93level=94 other than vt=
> able
> > optimization and -flimit-debug-info?
> >
> 
> None that spring immediately to my mind.
> 
> 
> > I think it would make sense to keep the -flimit-debug-info name as the
> > umbrella flag name;
> 
> 
> While I realize I disagreed with you about this earlier in the thread, I've
> mostly come around here, in the sense that I hope most users using this
> flag are using it because what they really want is "I'm compiling part of
> my project with debug info enabled and can't rely on other compile units to
> have debug info".
> 
> Though there's probably some users with -fno-limit-debug-info because it
> was broken...
> 
> 
> > it=92s a generic term and our users are already vaguely familiar with it.
> 
> 
> I think it's too generic and our users may only be familiar with it when it
> hurt them, without knowing why (without knowing whether it was a bug, for
> example).
> 
> 
> > On top of that, before last week, we didn=92t even bother documenting wha=
> t
> > the flag does exactly anyway, so there is little harm in changing its
> > semantics to cover additional fine-grained flags.
> >
> 
> Mostly agree.
> 
> 
> > Then we could introduce a more descriptive name for what used to be
> > -flimit-debug-info, e.g., -fno-forward-decl-debug-types (better suggestio=
> ns
> > are welcome)
> >
> > 1) -flimit-debug-info
> >
> 
> I'd still be inclined to introduce a better name for -flimit-debug-info as
> an alias that we document going forward. Possibly in the affirmative
> "-fstandalone-debug" (ie: emit all the relevant debug info as if this
> translation unit were standalone/had no reliance on other object files).
> Open to other names. Or perhaps this is the right place to reuse GCC's
> -femit-class-debug-always?

I really like the -fstandalone-debug name as an umbrella.

> 
> Personally I'm OK stopping there and not providing fine-grained access to
> the two separate optimizations until we have a use-case.
> 
> If someone really wants subflags (Chandler mentioned a preference, but I
> assume it's not binding/authoritative) I'm happy to bikeshed their names.
> 

I’m all for avoiding the bikeshedding, so let’s revisit that when we find a use-case.

> -femit-class-debug-on-complete-types ? I don't know - it'll be verbose no
> matter how we phrase it.
> 
> -femit-class-debug-on-dynamic-types
> 
> 
> >     |
> >     +- -fno-forward-decl-debug-types (the old limit-debug-info)
> >     |
> >     +- -fno-emit-class-debug-always (the new flag)
> >
> 
> Eric mentioned that on a cursory inspection of GCC, this flag controlled
> other things as well as the vtable optimization and he might not be
> comfortable using that name while not implementing the same semantics as
> GCC.
> 

That is fine with me.

We could introduce -fstandalone-debug as a new alias to -fno-limit-debug-info and make the vtable optimization contingent on debug level being =< standalone (née limited), and make -flimit-debug-info into a hidden backwards compatibility option and document -fstandalone-debug in the manpage and online help.

Would that work for you?

-- adrian
> 
> >
> > If we don=92t want to change the meaning of limited debug info, we could =
> have
> >
> > 2) -fpartial-debug-info (a new umbrella flag)
> >     |
> >     +- -flimit-debug-info (unchanged)
> >     |
> >     +- -fno-emit-class-debug-always (idem)
> >
> > I=92m leaning slightly towards option 1.
> >
> > > (though we could probably do an analysis on -flimit-debug-info and see
> > what
> > > the size win really is since it's been fixed - maybe it's not even wort=
> h
> > > keeping and we could just make the flag a no-op instead)
> > Did I hear somebody volunteering?
> >
> 
> Possibly, at some point.
>