Re: [PATCH 12/23] kbuild: avoid re-running compiler and linker probes

[Lorenzo Stoakes (ARM)]

On Fri, Sep 11, 2026 at 08:10:26PM +0200, Nicolas Schier wrote:
> On Fri, Sep 11, 2026 at 11:30:12AM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Thu, Sep 10, 2026 at 05:42:35PM +0200, Nicolas Schier wrote:
> > > On Wed, Sep 09, 2026 at 09:19:12PM -0700, Nathan Chancellor wrote:
> > > > > diff --git a/init/Kconfig b/init/Kconfig
> > > > > index 8583d9f06c52..3c92c87254a3 100644
> > > > > --- a/init/Kconfig
> > > > > +++ b/init/Kconfig
> > > > > @@ -144,6 +144,44 @@ config CC_HAS_ASSUME
> > > > >  config CC_HAS_NO_PROFILE_FN_ATTR
> > > > >  	def_bool $(success,echo '__attribute__((no_profile_instrument_function)) int x();' | $(CC) -x c - -c -o /dev/null -Werror)
> > > > >
> > > > > +config CC_HAS_ZERO_INIT_PADDING_BITS
> > > > > +	def_bool $(cc-option,-fzero-init-padding-bits=all)
> > > > > +
> > > > > +config CC_HAS_NO_STACK_CLASH_PROTECTION
> > > > > +	def_bool $(cc-option,-fno-stack-clash-protection)
> > > > > +
> > > > > +config CC_HAS_NO_ADDRSIG
> > > > > +	def_bool $(cc-option,-fno-addrsig)
> > > >
> > > > I am generally in favor of this proposal since I think these checks
> > > > should be cached by Kconfig where possible to clear up running them
> > > > twice. That said, I wonder if we should pick a better dumping ground for
> > > > these checks other than init/Kconfig. Maybe init/Kconfig.tools or
> > > > scripts/Kconfig.tools or something?
> > >
> >
> > (Sorry hadn't seen you'd replied also!)
> >
> > > Yes, skimming through the patch, I thought about that, too.  Moving more
> > > cc option checks to Kconfig will make building out-of-tree kmods with a
> > > different compiler more dangerous.  Maybe we will have to make the
> > > warning in Makefile's prepare (external kmods) target a bit louder.
> >
> > I guess this bit can be a follow up potentially?
>
> yes, sure.
>
> > >
> > > > I also worry about backsliding and growing cc-option checks. Should we
> > > > update the documentation to state that it is preferrable for these
> > > > checks to live in Kconfig so that they can be properly cached?
> > >
> > > Sounds good, yes.
> >
> > I can add a doc update as part of this series, unless you guys want to handle
> > separately?
>
> I don't think it has to be part of the series, it's long enough already.
> But if you want to prepare some docmentation about the preference of
> cc-option checks, feel free to go ahead or not.

Ack, thanks!

>
> Kind regards
> Nicolas

--
Cheers, Lorenzo