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

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

[Harish.Sadineni]

From: Harish Sadineni <Harish.Sadineni@windriver.com>

Convert the existing GCC tool definitions to use the `:toolchain-gcc`
override so they only apply when `TOOLCHAIN = "gcc"` (the default).

Introduce new definitions for `:toolchain-clang` that use clang,
ld.lld, llvm-ar, llvm-objcopy, and llvm-strip, allowing the kernel
to be built with the LLVM/Clang toolchain.

Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
---
 meta/classes-recipe/kernel-arch.bbclass | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

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"
-- 
2.49.0

[PATCH v2 2/4] kernel-yocto-rust: use clang toolchain for riscv64 when Rust is enabled

[Harish.Sadineni]

From: Harish Sadineni <Harish.Sadineni@windriver.com>

Enable LLVM/Clang toolchain for riscv64 kernel builds when Rust support
is enabled, as Rust is only supported with LLVM toolchains for this
architecture.

This aligns with upstream kernel Rust architecture requirements as
documented in:
https://docs.kernel.org/rust/arch-support.html

Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto.inc | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
index 4e230d405a..5d047b5f01 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -91,3 +91,7 @@ do_devshell:prepend() {
     d.setVar("HOSTPKG_CONFIG", "pkg-config-native")
     d.appendVar("OE_TERMINAL_EXPORTS", " HOSTPKG_CONFIG")
 }
+
+# For riscv64, Rust support in kernel only works with LLVM/Clang only.
+# https://docs.kernel.org/rust/arch-support.html
+TOOLCHAIN:riscv64 = "${@bb.utils.contains('KERNEL_FEATURES', 'rust', 'clang', 'gcc', d)}"
-- 
2.49.0

[PATCH v2 3/4] kernel-yocto-rust: Add lld-native to DEPENDS

[Harish.Sadineni]

From: Harish Sadineni <Harish.Sadineni@windriver.com>

Add lld-native to DEPENDS, As lld linker is required while building kernel
with clang.

Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
---
 meta/classes-recipe/kernel-yocto-rust.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes-recipe/kernel-yocto-rust.bbclass b/meta/classes-recipe/kernel-yocto-rust.bbclass
index 49f2bfc1ae..1badb37476 100644
--- a/meta/classes-recipe/kernel-yocto-rust.bbclass
+++ b/meta/classes-recipe/kernel-yocto-rust.bbclass
@@ -25,3 +25,6 @@ do_kernel_configme:append () {
 # More details in: https://lists.openembedded.org/g/openembedded-core/message/229336
 # Disable ccache for kernel build if kernel rust support is enabled to workaround this.
 CCACHE_DISABLE ?= "1"
+
+DEPENDS:append:riscv64 = " lld-native"
+RUST_KERNEL_TASK_DEPENDS:append:riscv64 = " lld-native:do_populate_sysroot"
-- 
2.49.0

[PATCH v2 4/4] kernel-yocto: Set CLANG_FLAGS for kernel config checks when using clang

[Harish.Sadineni]

From: Harish Sadineni <Harish.Sadineni@windriver.com>

When building with `TOOLCHAIN = "clang"`, the kernel's configuration
check (do_kernel_configcheck) fails with:

  kconfiglib.KconfigError: scripts/Kconfig.include:51: Sorry, this
  assembler is not supported.

Fix by setting `CLANG_FLAGS = "-fintegrated-as"` in the environment
when `TOOLCHAIN` contains "clang". This variable is used by the kernel
build system (via scripts/Kconfig.include) to pass additional flags to
clang during config checks, ensuring the assembler test passes.

Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
---
 meta/classes-recipe/kernel-yocto.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes-recipe/kernel-yocto.bbclass b/meta/classes-recipe/kernel-yocto.bbclass
index e7fdeb5d4b..cda9ffcf9c 100644
--- a/meta/classes-recipe/kernel-yocto.bbclass
+++ b/meta/classes-recipe/kernel-yocto.bbclass
@@ -603,6 +603,9 @@ python do_kernel_configcheck() {
     env['STRIP'] = d.getVar('KERNEL_STRIP')
     env['ARCH'] = d.getVar('ARCH')
     env['srctree'] = s
+    toolchain = d.getVar('TOOLCHAIN')
+    if 'clang' in toolchain:
+        env['CLANG_FLAGS'] = " -fintegrated-as"
 
     try:
         configs = subprocess.check_output(['scc', '--configs', '-o', s + '/.kernel-meta'], env=env).decode('utf-8')
-- 
2.49.0

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

[Bruce Ashfield]

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

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

[Harish Sadineni]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 3205 bytes --]