<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 29, 2020 at 3:38 PM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Jul 28, 2020, at 11:50 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> <br>
> Context: While staging the constructor-based type homing we intended<br>
> to rollout enabling this by default in Google prior to changing the<br>
> default upstream to make it easier to test and rollback (& also having<br>
> the ability to turn it off even once it's on by default in case other<br>
> issues are discovered - either that don't rise to the level of needing<br>
> a rollback, or at least to allow forward progress without having to<br>
> wait on/merge an upstream rollback)<br>
> <br>
> Turns out we don't have a way to change the debug-info-kind default,<br>
> without actually specifying debug-info-kind which enables debug info<br>
> even when that isn't desired. (eg: we'd like to change the build<br>
> system default, but allow users/build rules/etc to opt in/out of debug<br>
> info as needed)<br>
> <br>
> This solution doesn't need to (& might be better off not being) a<br>
> driver flag, could be just a cc1 flag - I don't think we want to<br>
> support users generally opting in/out of these things in a<br>
> fine-grained way (same argument I made years ago about grouping the<br>
> existing 3 homing strategies (complete type, explicit template<br>
> specialization definition, vtable definition) together under one flag,<br>
> -f[no-]standalone-debug).<br>
> <br>
> 1) wire up constructor homing as a separate cc1 flag that composes<br>
> with -debug-info-kind: does nothing except when<br>
> -debug-info-kind=limited is specified, and then it makes limited more<br>
> aggressive by using the constructor homing technique (yeah, this was<br>
> the original proposed version of the patch, I think - and, looking<br>
> back on it, given the desire to eventually fold this into limited<br>
> anyway, maybe that was the right direction from the start)<br>
<br>
something like -debug-info-limit-kind=[constructor|vtable] ?<br>
<br></blockquote><div><br></div><div>Yeah. This was my thought, basically have how we limit the debug information be different than the kind of debug information:</div><div><br></div><div>amount: none, line tables, full</div><div><br></div><div>limits: none, constructor, vtable, all?</div><div> </div><div>all would be a limit, for example, for Nick's no unused types thing?</div><div><br></div><div>Additional modifiers (to be complicated) could be "split" or not.</div><div><br></div><div>Thoughts?</div><div><br></div><div>-eric</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> 2) take out all the debug-info-kind layers above "limited" (so,<br>
> limited, constructor, full) into a separate flag like<br>
> "debug-info-type-kind" (maybe that name's a bit subtle - since this<br>
> flag would not enable debug info by default, but debug-info-kind<br>
> does/would continue to). That way existing "-debug-info-kind=limited"<br>
> would be "-debug-info-kind=type -debug-info-type-kind=limited", for<br>
> instance.<br>
<br>
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.<br>
<br>
<br>
> 3) ... other ideas?<br>
<br>
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 ;-)<br>
<br>
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.<br>
<br>
-- adrian</blockquote></div></div>