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

[Eric Christopher 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] ?
>
>
Yeah. This was my thought, basically have how we limit the debug
information be different than the kind of debug information:

amount: none, line tables, full

limits: none, constructor, vtable, all?

all would be a limit, for example, for Nick's no unused types thing?

Additional modifiers (to be complicated) could be "split" or not.

Thoughts?

-eric

>
> > 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.
>
>
> > 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. I am not going to encourage using
> CCC_OVERRIDE_OPTIONS for this ;-)
>
> 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.
>
> -- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200729/d9988d13/attachment-0001.html>