Re: [OE-core] [PATCH v2 1/4] kernel-arch: Add clang toolchain support

[Bruce Ashfield <bruce.ashfield@gmail.com>]

On Mon, Jul 7, 2026, Harish Sadineni wrote:
> Convert the existing GCC tool definitions to use the `:toolchain-gcc`
> override so they only apply when `TOOLCHAIN = "gcc"` (the default).

I went through the series with a focus on making sure it's a no-op for the
common gcc / non-riscv64 kernel build, and it checks out:

 - toolchain-gcc lands in OVERRIDES for a default build (base.bbclass does
   inherit_defer toolchain/${TOOLCHAIN}, gcc.bbclass sets
   TCOVERRIDE = "toolchain-gcc", and OVERRIDES carries ${TCOVERRIDE}), so
   KERNEL_CC:toolchain-gcc et al resolve to exactly what the unconditional
   assignments produced before.

 - The KERNEL_CC:append:{aarch64,nios2,arc} appends in linux-yocto.inc still
   stack correctly on top of the :toolchain-gcc value, so the arch-specific
   TOOLCHAIN_OPTIONS aren't lost.

 - Patches 2-4 are gated to riscv64 and/or the rust KERNEL_FEATURE
   (kernel-yocto-rust.bbclass is only inherited when 'rust' is set), so
   they're inert everywhere else.

For the whole series:

Acked-by: Bruce Ashfield <bruce.ashfield@gmail.com>

Two things worth noting, neither blocking:

 - One behavioural subtlety from this conversion: a KERNEL_CC:toolchain-gcc
   assignment now outranks any *unconditional* KERNEL_CC = "..." a downstream
   BSP might set, where previously it was a plain last-assignment-wins. No
   in-tree machine/recipe does that today, so there's no regression, but it's
   a change in precedence worth being aware of if a BSP overrides these.

 - In patch 4, `if 'clang' in toolchain:` will throw if TOOLCHAIN is ever
   unset (getVar returns None). It's always set for kernel recipes today so
   it's fine, but `d.getVar('TOOLCHAIN') or ''` would be a touch more robust.

Bruce