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

On Sat, Sep 12, 2026 at 12:11:28AM -0700, Nathan Chancellor wrote:

On Fri, Sep 11, 2026 at 07:24:50PM +0100, Lorenzo Stoakes (ARM) wrote:

quoted

I mean this is a problem that already exists for any flags already specified in
Kconfig.

Out-of-tree modules are historically something that we don't go to great lengths
to support and haven't historically worried about breaking, either.

I'm sure distros can find ways around this if a problem were to arise. But I
don't think it's something to worry about all that much.

I expect a _lot_ of these, in any case, would only require the compilers to be
within a fair few major versions of one another anyway.

Yeah, while I know distributions will try to maintain a stable kernel
ABI to allow updating modules without updating the main kernel, I would
be very very surprised if they guaranteed compatability when building
external modules with a compiler different from the main kernel. If so,
I think they get to pick up the pieces :)

One issue that I found with my test matrix building with LLVM is that
cc-option in Kconfig does not guarantee use of either '-m32' / '-m64' or
'-mbig-endian' / '-mlittle-endian' to properly flip these options, which
could result in a flag being set (or not set) when it should be. For
example, building ARCH=powerpc pmac32_defconfig results in

  clang: error: argument unused during compilation: '-fno-stack-clash-protection' [-Werror,-Wunused-command-line-argument]
  make[4]: *** [scripts/Makefile.build:193: kernel/bounds.s] Error 1

because the 64-bit PowerPC little endian target supports this flag in
the PowerPC LLVM backend but the 32-bit big endian target does not.

Ack, reproduced locally thanks!

I had the LLM probe every flag the patch moves in both directions with
clang across ppc32/64 BE and LE, x86 -m32, mips 32/64, rv32, s390x, arm and
arm64 BE and with gcc -m32.

(We really have to stop supporting some of this stuff...!)

It seems that only -fno-stack-clash-protection is problematic for
ppc32/clang.

So in v2 I'll keep that probe in the Makefile and move the rest, have
confirmed that fixes the problem.

I am not really sure what the best way to avoid this would be off the
top of my head... it might be safer to start with moving only the
warning flags to Kconfig since that is a truly frontend query.

Given the testing above I think we _should_ be OK :)

--
Cheers,
Nathan

--
Cheers, Lorenzo