[cfe-dev] Debug info level specification with the clang driver

[David Blaikie via cfe-dev]

On Wed, Jul 29, 2020 at 3:38 PM Adrian Prantl <aprantl at apple.com> wrote:
>
>
>
> > On Jul 28, 2020, at 11:50 AM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > Context: While staging the constructor-based type homing we intended
> > to rollout enabling this by default in Google prior to changing the
> > default upstream to make it easier to test and rollback (& also having
> > the ability to turn it off even once it's on by default in case other
> > issues are discovered - either that don't rise to the level of needing
> > a rollback, or at least to allow forward progress without having to
> > wait on/merge an upstream rollback)
> >
> > Turns out we don't have a way to change the debug-info-kind default,
> > without actually specifying debug-info-kind which enables debug info
> > even when that isn't desired. (eg: we'd like to change the build
> > system default, but allow users/build rules/etc to opt in/out of debug
> > info as needed)
> >
> > This solution doesn't need to (& might be better off not being) a
> > driver flag, could be just a cc1 flag - I don't think we want to
> > support users generally opting in/out of these things in a
> > fine-grained way (same argument I made years ago about grouping the
> > existing 3 homing strategies (complete type, explicit template
> > specialization definition, vtable definition) together under one flag,
> > -f[no-]standalone-debug).
> >
> > 1) wire up constructor homing as a separate cc1 flag that composes
> > with -debug-info-kind: does nothing except when
> > -debug-info-kind=limited is specified, and then it makes limited more
> > aggressive by using the constructor homing technique (yeah, this was
> > the original proposed version of the patch, I think - and, looking
> > back on it, given the desire to eventually fold this into limited
> > anyway, maybe that was the right direction from the start)
>
> something like -debug-info-limit-kind=[constructor|vtable] ?
>
> >
> > 2) take out all the debug-info-kind layers above "limited" (so,
> > limited, constructor, full) into a separate flag like
> > "debug-info-type-kind" (maybe that name's a bit subtle - since this
> > flag would not enable debug info by default, but debug-info-kind
> > does/would continue to). That way existing "-debug-info-kind=limited"
> > would be "-debug-info-kind=type -debug-info-type-kind=limited", for
> > instance.
>
> As long as all the debug info kinds fit onto one axis where the next-higher kind adds more debug info than the previous level it feels weird to split out some of the options. I guess what you really want is to remove -debug-info-kind=none and split that out. At the cc1 level, we probably want one flag that does nothing but turn on debug info (-emit-debug-info?), and all other debug info flags just control what is emitted, if that control flag is set.

Fair point, for sure. I'd have to think a bit more about whether
that'd be adequate for our use case... hmm, maybe not. I think maybe
-Xclang flags come after all the driver-computed flags, so "clang
-Xclang -debug-info-kind=constructor -gmlt" would still produce

> > 3) ... other ideas?
>
> If this is primarily about rolling out the change at Google, you could add a custom google-specific option in your private branch and remove it once the transition is complete.

Nah - more about the general needs of rolling this out by default in
the compiler upstream. It's invasive enough (& we've seen breakage)
that having it behind a flag rather than rolling a patch
forward/backwards seems best. Flag off by default first, let users
(Google among them, to be sure) test it out, then switch the default
but still have the flag in case longer tail issues come up & it's
better to be able to switch it off immediately than try to reroll the
compiler.

But, yeah, I imagine Google's coverage here might be pretty good given
we're interested in both GDB and LLDB functionality right now (&
things like ThinLTO, where some breakage has shown up).

> I am not going to encourage using CCC_OVERRIDE_OPTIONS for this ;-)

Can't say I'm familiar with that.

> I think I could live with option 1, but I think splitting out a separate option just for turning debug info on an off is the most elegant solution. It's also the option that needs most infrastructure work in build systems that produce cc1 options.

I think this won't quite do what we need.

We have existing usage that has debug info levels on a perf-file basis
(eg: "compile everything with -g, except these files override that
with -gmlt") If we want to change the default to ctor homing, but
still respect that customization, I'm not sure this separation of cc1
flags would suffice.

We'd end up with command lines like:

clang -Xclang -debug-info-kind=constructor x.cpp
 => clang -cc1 -debug-info-kind=constructor  // great, doesn't turn on
debug info where it wasn't asked for
clang -Xclang -debug-info-kind=constructor x.cpp -g // great, turns on
debug info and switches it to ctor homing
 => clang -cc1 -emit-debug-info -debug-info-kind=limited
-debug-info-kind=constructor // great, turns on debug info and
switches it to ctor homing
clang -Xclang -debug-info-kind=constructor x.cpp -g -gmlt // still get
full constructor-homed debug info instead of gmlt
 => clang -cc1 -emit-debug-info -debug-info-kind=line-tables-only
-debug-info-kind=constructor // still get full constructor-homed debug
info instead of gmlt

The issue is that -Xclang (sort of rightly?) doesn't respect its
ordering in the command line. -Xclangs come after (almost...) all the
driver-created arguments