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

[Lorenzo Stoakes (ARM)]

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:
> > 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