Re: [PATCH v3 11/20] kbuild: avoid re-running compiler and linker probes

On Thu, Sep 17, 2026 at 12:26:48PM -0700, Kees Cook wrote:
> On Thu, Sep 17, 2026 at 05:06:21PM +0100, Lorenzo Stoakes (ARM) wrote:
> > Each kernel make invocation begins with ~30 compiler and linker runs each
> > of which performs duplicate probe for a number of compiler and linker
> > options.
> > 
> > This is useless work - the compiler and its version is known, so use these
> > to determine which options are available, once.
> > 
> > A convention already exists for this - CC_HAS_xxx, LD_HAS_xxx in Kconfig
> > files (for example, CC_HAS_COUNTED_BY), so convert these probes to Kconfig
> > options where appropriate.
> 
> Yeah, I agree about the rationale here.
> 
> It does, however, now drive a long-time annoyance of mine to the top of
> mind: the repetition of the compiler command-line options in two places:
> the Kconfig and the Makefile. I dislike that pattern so much that I really
> really worked hard to use cc-option instead where ever I possibly could
> (though it continued to add to my growing concern about the repetition
> of running those checks all the time, so I'm motivated to see something
> like what you have here actually land).
> 
> But I would really like to find a way to avoid the duplication. It's
> fragile and it's weird and it's split across 2 files that don't always
> have an obvious relationship. I really don't like it. And with it being
> used for things that are "detected" (i.e. not part of always required
> builds), that fragility means typos may go unnoticed, etc.
> 
> We've had a need for some kind of kconfig "append to a list" logic that
> we've been working around in places, e.g. include/linux/lsm_count.h for
> how "count the list of enabled LSMs" got dealt with. If we could have
> had:
> 
> config LSM_LIST
> 	list
> 	separator " "
> 
> config SECURITY_SELINUX
> 	...
> 	append_to LSM_LIST
> 	...
> 
> We could just parse CONFIG_LSM_LIST directly. And I think we can do the
> same with this:
> 
> config CC_OPTION_LIST
> 	list
> 	separator " "
> 
> config CC_OPTION_ZERO_INIT_PADDING_BITS
> 	string
> 	default "$(cc-option-bit,-fzero-init-padding-bits=all)"
> 	append_to CC_OPTION_LIST
> 
> And the dump all of it into the Makefile in one via CONFIG_CC_OPTION_LIST
> 
> (And we'd need to implement ld-option-bit. Though really I think
> cc-option-bit should be renamed to cc-option-str or something)
> 
> But even without the new "list" Kconfig type, it'd be nicer to use the
> cc-option-bit string default method and dump all the newly created
> CC_OPTION_... strings into the makefile manually. The "append_to" idea
> could be a follow-up.

While we could certainly try to cook something like this up, we could
also avoid the split across two files by just defining the flags in
Kconfig directly and using them in the Makefile through their symbol,
like we already do for -Wimplicit-fallthrough. For example, instead of

  config CC_HAS_STRICT_FLEX_ARRAYS
      def_bool $(cc-option,-fstrict-flex-arrays=3)

  KBUILD_CFLAGS += $(if $(CONFIG_CC_HAS_STRICT_FLEX_ARRAYS),-fstrict-flex-arrays=3)

We would just do

  config CC_STRICT_FLEX_ARRAYS
      string
      default "-fstrict-flex-arrays=3" if $(cc-option,-fstrict-flex-arrays=3)

  KBUILD_CFLAGS += $(CONFIG_CC_STRICT_FLEX_ARRAYS)

While we still get the duplication (and we could look at getting rid of
it with your cc-option-str idea or whatever), it is at least contained
to the same location, so out of sync issues should be much rarer. I do
diff Kconfigs so this might make certain issues with checks a little bit
more obvious if something changes on the compiler side.

-- 
Cheers,
Nathan