Debug info level specification with the clang driver

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Debug info level specification with the clang driver

Keane, Erich via cfe-dev
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)

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.

3) ... other ideas?
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Debug info level specification with the clang driver

Keane, Erich via cfe-dev

On 2020-07-28, David Blaikie wrote:

>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)
>
>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.
>
>3) ... other ideas?

2) seems to involve more design discussions:) ?
If it takes a while to reach concensus whether we should do 2), doing 1) for
-debug-info-kind=constructor seems fine: we just have last few bugs that block
folding it into limited. It is a temporary CC1 option which has very little
cost.

I have done very little debug work, so please just count my vote as +0.2 :)
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Debug info level specification with the clang driver

Keane, Erich via cfe-dev
In reply to this post by Keane, Erich via cfe-dev


> On Jul 28, 2020, at 11:50 AM, David Blaikie <[hidden email]> 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.


> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Debug info level specification with the clang driver

Keane, Erich via cfe-dev


On Wed, Jul 29, 2020 at 3:38 PM Adrian Prantl <[hidden email]> wrote:


> On Jul 28, 2020, at 11:50 AM, David Blaikie <[hidden email]> 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

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Debug info level specification with the clang driver

Keane, Erich via cfe-dev
> 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.

What Adrian said.  The notion of a "limit" seems like it is really
only refining what happens above "line tables."  Not clear there’s
a benefit to having two separate controls there.
--paulr

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Debug info level specification with the clang driver

Keane, Erich via cfe-dev
In reply to this post by Keane, Erich via cfe-dev
On Wed, Jul 29, 2020 at 3:38 PM Adrian Prantl <[hidden email]> wrote:

>
>
>
> > On Jul 28, 2020, at 11:50 AM, David Blaikie <[hidden email]> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Debug info level specification with the clang driver

Keane, Erich via cfe-dev
In reply to this post by Keane, Erich via cfe-dev
On Thu, Jul 30, 2020 at 11:16 AM Robinson, Paul <[hidden email]> wrote:

>
> > 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.
>
> What Adrian said.  The notion of a "limit" seems like it is really
> only refining what happens above "line tables."  Not clear there’s
> a benefit to having two separate controls there.

Hopefully my example to Adrian on this thread helps explain the motivation.

Essentially we want some flag we can always pass that enables ctor
homing when type information is emitted, but doesn't affect things
otherwise.

i.e, something that does this:
clang -g x.cpp // no new flag, classic vtable homing
clang <flag> x.cpp // no debug info
clang <flag> -g x.cpp // constructor homing, despite the vtable homing default
clang <flag> -g x.cpp -gmlt // gmlt debug info - no homing, because no
types are emitted here
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev