| Message ID | 20260707085552.981820-1-Harish.Sadineni@windriver.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,1/4] kernel-arch: Add clang toolchain support | expand |
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
On 08-07-2026 07:49 am, Bruce Ashfield wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > 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. Hi Bruce, Thanks for the ack. I've sent v3 with your suggested d.getVar('TOOLCHAIN') or '' fix folded into patch 4 (the only change since v2), and carried your Acked-by forward on all patches.https://lists.openembedded.org/g/openembedded-core/message/240489 Thanks, Harish > > Bruce
diff --git a/meta/classes-recipe/kernel-arch.bbclass b/meta/classes-recipe/kernel-arch.bbclass index 7aea9cd3e8..6ebc0f13ea 100644 --- a/meta/classes-recipe/kernel-arch.bbclass +++ b/meta/classes-recipe/kernel-arch.bbclass @@ -71,14 +71,25 @@ HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}" TARGET_OBJCOPY_KERNEL_ARCH ?= "" HOST_OBJCOPY_KERNEL_ARCH ?= "${TARGET_OBJCOPY_KERNEL_ARCH}" -KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH} \ +KERNEL_CC:toolchain-gcc = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH} \ -fuse-ld=bfd ${DEBUG_PREFIX_MAP} \ -ffile-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH} \ -ffile-prefix-map=${STAGING_KERNEL_BUILDDIR}=${KERNEL_SRC_PATH} \ " -KERNEL_LD = "${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}" -KERNEL_AR = "${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}" -KERNEL_OBJCOPY = "${HOST_PREFIX}objcopy ${HOST_OBJCOPY_KERNEL_ARCH}" +KERNEL_LD:toolchain-gcc = "${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}" +KERNEL_AR:toolchain-gcc = "${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}" +KERNEL_OBJCOPY:toolchain-gcc = "${HOST_PREFIX}objcopy ${HOST_OBJCOPY_KERNEL_ARCH}" # Code in package.py can't handle options on KERNEL_STRIP -KERNEL_STRIP = "${HOST_PREFIX}strip" +KERNEL_STRIP:toolchain-gcc = "${HOST_PREFIX}strip" + + +KERNEL_CC:toolchain-clang = "${CCACHE}clang ${HOST_CC_KERNEL_ARCH} \ + ${DEBUG_PREFIX_MAP} \ + -ffile-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH} \ + -ffile-prefix-map=${STAGING_KERNEL_BUILDDIR}=${KERNEL_SRC_PATH} \ +" +KERNEL_LD:toolchain-clang = "ld.lld ${HOST_LD_KERNEL_ARCH}" +KERNEL_AR:toolchain-clang = "llvm-ar ${HOST_AR_KERNEL_ARCH}" +KERNEL_OBJCOPY:toolchain-clang = "llvm-objcopy ${HOST_OBJCOPY_KERNEL_ARCH}" +KERNEL_STRIP:toolchain-clang = "llvm-strip" TOOLCHAIN = "gcc"