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

Nathan Chancellor <[email protected]>
Newsgroups org.kernel.vger.linux-doc,dev.linux.lists.llvm,org.infradead.lists.linux-riscv,org.kernel.vger.linux-arch,org.kernel.vger.linux-efi,org.kernel.vger.linux-hardening,org.kernel.vger.linux-kbuild,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux
Message-ID <20260918054058.GA384222@ax162>
On Thu, Sep 17, 2026 at 09:44:24PM -0700, Kees Cook wrote:
> On Thu, Sep 17, 2026 at 06:21:19PM -0700, Nathan Chancellor wrote:
> > 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.
> 
> Yeah, and note that cc-option-bit already exists. It's just a weird name
> is all and there isn't an ld-option-bit.

Ah, I see. I worry that the current cc-option-bit is not sufficient for
all options that we may want to test because it uses '-E' to stop after
preprocessing (whereas some options may need to get to code generation
to be validated properly) and it does not use $(CLANG_FLAGS) to properly
set the target (so we might not get consistent results). I wonder if we
would be better off refactoring cc-option-bit into cc-option-str that
shares most of the machinery of cc-option. Then we could just add
ld-option-str.

> As for naming conventions, I think "CC_OPT_" would be a good prefix. And
> this works today with no change:
> 
> config CC_OPT_STRICT_FLEX_ARRAYS
> 	string
> 	default "$(cc-option-bit,-fstrict-flex-arrays=3)"

This does look pretty nice.

> (do we need "def_string" now?)

def_string would certainly make these even nicer.

-- 
Cheers,
Nathan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.