Support x86 (i.e. 32-bit)

While x86 (i.e. 32-bit) will become less important over time, it is a key architecture of the kernel (and the original one, too). In addition, it is a non-64 bit target (which helps widening our tests to uncover potential issues) and it is a target that pretty much everyone can natively run. Thus we should support it.

Linux x86 targets with official Ubuntu binutils etc. support:

Linux arch  QEMU target     LLVM target  Ubuntu binutils            Example Rust triple
----------  --------------  -----------  -------------------------  ----------------------

x86         i386-softmmu    X86          binutils-i686-linux-gnu    i686-unknown-linux-gnu
x86         x86_64-softmmu  X86          binutils-x86-64-linux-gnu  x86_64-linux-kernel

rust: support x86 (i.e. 32-bit)

bpf: Fix a few selftest failures due to llvm18 change

kcsan, seqlock: Support seqcount_latch_t

wifi: iwlwifi: Fix botched indexing conversion

While x86 (i.e. 32-bit) will become less important over time, it is a key architecture of the kernel (and the original one, too).

While we likely still want to get i386 to work, Debian Trixie does not support i386 kernels anymore -- from https://www.debian.org/releases/trixie/release-notes/issues.en.html#reduced-support-for-i386:

From trixie, i386 is no longer supported as a regular architecture: there is no official kernel and no Debian installer for i386 systems. Fewer packages are available for i386 because many projects no longer support it. The architecture’s sole remaining purpose is to support running legacy code, for example, by way of multiarch or a chroot on a 64-bit (amd64) system.

Has anybody tested i386 with -Zregparm and -Zreg-struct-return, or are there other blockers? It seems like it should work now, but I haven't seen anything on the lists.

@sulix

I don't think people has tried yet.

I just gave it a quick try, and there are some cleanups to do (block uses AtomicU64, DRM panic QR has a 64-bit div, Nova needs a couple cleanups, including this one).

In addition, we need https://lore.kernel.org/rust-for-linux/20250727092317.2930617-1-ojeda@kernel.org/ (which will land soon) plus a change on top of that for the two new flags.

All in all, one can play with it with a draft patch like (ignoring mitigations and cleanups):

Details

From 9db84aff6016fe3ed3917db41b6ba6c35fe8756c Mon Sep 17 00:00:00 2001
From: Miguel Ojeda <ojeda@kernel.org>
Date: Mon, 11 Aug 2025 13:39:34 +0200
Subject: [PATCH] [DRAFT] rust: add 32-bit x86 (i386) support

---
 arch/x86/Kconfig                | 2 +-
 arch/x86/Makefile               | 1 +
 drivers/gpu/drm/Kconfig         | 1 +
 drivers/gpu/drm/nova/Kconfig    | 1 +
 drivers/gpu/nova-core/Kconfig   | 1 +
 init/Kconfig                    | 1 +
 rust/Makefile                   | 5 ++++-
 rust/compiler_builtins.rs       | 6 ++++++
 scripts/generate_rust_target.rs | 4 ----
 9 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 58d890fe2100..45523a5251c6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -295,7 +295,7 @@ config X86
 	select HAVE_STATIC_CALL_INLINE		if HAVE_OBJTOOL
 	select HAVE_PREEMPT_DYNAMIC_CALL
 	select HAVE_RSEQ
-	select HAVE_RUST			if X86_64
+	select HAVE_RUST
 	select HAVE_SYSCALL_TRACEPOINTS
 	select HAVE_UACCESS_VALIDATION		if HAVE_OBJTOOL
 	select HAVE_UNSTABLE_SCHED_CLOCK
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 1913d342969b..f65aa1f012e3 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -123,6 +123,7 @@ ifeq ($(CONFIG_X86_32),y)
         KBUILD_CFLAGS += -m32
 
         KBUILD_CFLAGS += -msoft-float -mregparm=3 -freg-struct-return
+        KBUILD_RUSTFLAGS += -Zregparm=3 -Zreg-struct-return
 
         # Never want PIC in a 32-bit kernel, prevent breakage with GCC built
         # with nonstandard options
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f7ea8e895c0c..3ced8d143eec 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -101,6 +101,7 @@ config DRM_PANIC_SCREEN
 config DRM_PANIC_SCREEN_QR_CODE
 	bool "Add a panic screen with a QR code"
 	depends on DRM_PANIC && RUST
+	depends on !X86_32
 	select ZLIB_DEFLATE
 	help
 	  This option adds a QR code generator, and a panic screen with a QR
diff --git a/drivers/gpu/drm/nova/Kconfig b/drivers/gpu/drm/nova/Kconfig
index cca6a3fea879..46fee725508d 100644
--- a/drivers/gpu/drm/nova/Kconfig
+++ b/drivers/gpu/drm/nova/Kconfig
@@ -3,6 +3,7 @@ config DRM_NOVA
 	depends on DRM=y
 	depends on PCI
 	depends on RUST
+	depends on !X86_32
 	select AUXILIARY_BUS
 	default n
 	help
diff --git a/drivers/gpu/nova-core/Kconfig b/drivers/gpu/nova-core/Kconfig
index 8726d80d6ba4..a3f3c9a3f80e 100644
--- a/drivers/gpu/nova-core/Kconfig
+++ b/drivers/gpu/nova-core/Kconfig
@@ -3,6 +3,7 @@ config NOVA_CORE
 	depends on PCI
 	depends on RUST
 	depends on RUST_FW_LOADER_ABSTRACTIONS
+	depends on !X86_32
 	select AUXILIARY_BUS
 	default n
 	help
diff --git a/init/Kconfig b/init/Kconfig
index 836320251219..795f5a2b7ddb 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2068,6 +2068,7 @@ config RUST
 	depends on !CALL_PADDING || RUSTC_VERSION >= 108100
 	depends on !KASAN_SW_TAGS
 	depends on !(MITIGATION_RETHUNK && KASAN) || RUSTC_VERSION >= 108300
+	depends on !X86_32 || !BLOCK
 	help
 	  Enables Rust support in the kernel.
 
diff --git a/rust/Makefile b/rust/Makefile
index d47f82588d78..7fce9c63ac1c 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -67,7 +67,7 @@ core-edition := $(if $(call rustc-min-version,108700),2024,2021)
 
 # `rustdoc` did not save the target modifiers, thus workaround for
 # the time being (https://github.com/rust-lang/rust/issues/144521).
-rustdoc_modifiers_workaround := $(if $(call rustc-min-version,108800),-Cunsafe-allow-abi-mismatch=fixed-x18)
+rustdoc_modifiers_workaround := $(if $(call rustc-min-version,108800),-Cunsafe-allow-abi-mismatch=fixed-x18$(comma)reg-struct-return$(comma)regparm)
 
 # `rustc` recognizes `--remap-path-prefix` since 1.26.0, but `rustdoc` only
 # since Rust 1.81.0. Moreover, `rustdoc` ICEs on out-of-tree builds since Rust
@@ -464,6 +464,9 @@ ifneq ($(or $(CONFIG_ARM64),$(and $(CONFIG_RISCV),$(CONFIG_64BIT))),)
 		__ashrti3 \
 		__ashlti3 __lshrti3
 endif
+ifdef CONFIG_X86_32
+	redirect-intrinsics += __udivdi3 __umoddi3
+endif
 
 ifdef CONFIG_MODVERSIONS
 cmd_gendwarfksyms = $(if $(skip_gendwarfksyms),, \
diff --git a/rust/compiler_builtins.rs b/rust/compiler_builtins.rs
index dd16c1dc899c..afc32b0299c9 100644
--- a/rust/compiler_builtins.rs
+++ b/rust/compiler_builtins.rs
@@ -97,5 +97,11 @@ pub extern "C" fn $ident() {
     __aeabi_uldivmod,
 });
 
+#[cfg(target_arch = "x86")]
+define_panicking_intrinsics!("`u64` division/modulo should not be used", {
+    __udivdi3,
+    __umoddi3,
+});
+
 // NOTE: if you are adding a new intrinsic here, you should also add it to
 // `redirect-intrinsics` in `rust/Makefile`.
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 39c82908ff3a..e5b9ee229ccf 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -227,10 +227,6 @@ fn main() {
         ts.push("supported-sanitizers", ["kcfi", "kernel-address"]);
         ts.push("target-pointer-width", "64");
     } else if cfg.has("X86_32") {
-        // This only works on UML, as i386 otherwise needs regparm support in rustc
-        if !cfg.has("UML") {
-            panic!("32-bit x86 only works under UML");
-        }
         ts.push("arch", "x86");
         if cfg.rustc_version_atleast(1, 86, 0) {
             ts.push("rustc-abi", "x86-softfloat");
-- 
2.50.1

With it, I can build fine, but I get null and 0x1 pointer derefs, which sound like wrong ABI, like when I tried years ago.

I took a quick look, and one of the crashes is on calling memset, which passes arguments pushing:

<bindings::bindings_raw::{impl#1376}::default+11>:	push   $0xb0
<bindings::bindings_raw::{impl#1376}::default+16>:	push   $0x0
<bindings::bindings_raw::{impl#1376}::default+18>:	push   %esi
<bindings::bindings_raw::{impl#1376}::default+19>:	call   0xc15dd5e0 <memset>

I created a similar case in Compiler Explorer, and indeed it seems to me that the ABI change is not getting applied for extern "C" { fn memset(...); }. If another name is used, it does:

use std::ffi;

unsafe extern "C" {
    pub fn memset(s: *mut ffi::c_void, c: ffi::c_int, count: usize) -> *mut ffi::c_void;
    pub fn my_memset(s: *mut ffi::c_void, c: ffi::c_int, count: usize) -> *mut ffi::c_void;
}

#[unsafe(no_mangle)]
pub fn f1(p: *mut ffi::c_void) {
    unsafe {
        memset(p, 0, 1234);
    }
}

#[unsafe(no_mangle)]
pub fn f2(p: *mut ffi::c_void) {
    unsafe {
        my_memset(p, 0, 1234);
    }
}

Is there a way to force the ABI for those too (e.g. @llvm.memset) or to avoid special handling at all of those well-known symbols perhaps (like -fno-builtin)?

https://godbolt.org/z/sPzeqxh3K

Cc: @sulix and the old #966 PR, @bjorn3 as well since he was there, @azhogin who worked on the flags, @nbdd0121 who knows a lot about ABIs etc.

(By the way, @azhogin, I don't see any tests/assembly* tests in Rust for e.g. -Zregparm -- I think we should have those as well, not just the LLVM IR one, like we do in other flags.)

Looks like some info is missing when Rust invokes LLVM, as the generated LLVM from Rust compiles correctly when I give it to a clang with -mregparm=3 -freg-struct-return: https://godbolt.org/z/dd17EY1xx

#![no_builtins] fixes it I think.

It's the NumRegisterParameters module flag https://llvm.godbolt.org/z/zoP199bPj. Good catch Miguel :)

Created rust-lang/rust#145271

As of my last attempt a couple of months ago, I ended up basically with the same set of issues Miguel mentioned.

The block device/atomics issues are fixed by https://lore.kernel.org/rust-for-linux/20250723233312.3304339-5-gary@kernel.org/

There were a bunch of KUnit failures which I'd also mostly tracked down to LLVM not using the regparm ABI options for builtins.

For proper support, arch/x86/Makefile_32.cpu needs the appropriate rustflags set, too (though that should be relatively easy).

But other than the -Zregparm issue, the resulting kernel was booting okay even on ancient hardware:
https://davidgow.net/stuff/rust-for-linux-i486-kunit.log

Thanks all!

Looks like some info is missing when Rust invokes LLVM, as the generated LLVM from Rust compiles correctly when I give it to a clang with -mregparm=3 -freg-struct-return: https://godbolt.org/z/dd17EY1xx

It's the NumRegisterParameters module flag https://llvm.godbolt.org/z/zoP199bPj. Good catch Miguel :)

Nice, that was fast guys :) Then it should be easy to fix (at least implementation-wise, I saw your other comment on the LLVM LangRef).

There were a bunch of KUnit failures which I'd also mostly tracked down to LLVM not using the regparm ABI options for builtins.

Yeah, I had bad derefs in KUnit, but it also happened when loading one of the new sample modules, i.e. I think we will be hitting this as soon as we have non-trivial modules.

The good news is that with the builtins fix above, all of those tests are passing for me.

The bad news is that I think we've got another -Zregparm=3 bug, which is triggered by the LKMM atomics work. It looks like rustc is spilling 64-bit arguments to the stack, even if there are enough registers to go around.

See, for instance https://godbolt.org/z/feb7addG7 — the argument is pushed onto the stack in rust, but in gcc (and also clang), it's stored in edx:eax. Given all of the rust_atomic64_* helpers accept a 64-bit integer argument, this makes the new rust_atomics tests fail and/or crash.

I've filed a rustc bug here: rust-lang/rust#145694

Thanks for taking a look David! I linked it in our lists. It seems to be that inreg is not annotated in extern declarations the same way as Clang would.

(Never mind, I just saw the messages in the other thread and that you already took a look).

Navigation Menu

Repository navigation

Support x86 (i.e. 32-bit) #78

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support x86 (i.e. 32-bit) #78

Description

Activity

ojeda commented on Aug 10, 2025

tgross35 commented on Aug 11, 2025

ojeda commented on Aug 11, 2025

nbdd0121 commented on Aug 11, 2025

bjorn3 commented on Aug 11, 2025

tgross35 commented on Aug 11, 2025

tgross35 commented on Aug 11, 2025

sulix commented on Aug 12, 2025

ojeda commented on Aug 12, 2025

sulix commented on Aug 21, 2025

ojeda commented on Aug 21, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions