Regressions on arm build with config rustgcc-lkftconfig-kselftest on the Linux mainline and next failed with CONFIG_RUST=y enabled.
First seen on the v6.14-13039-ge8b471285262 (April 3, 2025) Bad: v6.15-rc1 Good: v6.14-12966-ga2cc6ff5ec8f ( April 3, 2025 )
Bad: next-20250327 Good: next-20250326
* arm, build - rustgcc-lkftconfig-kselftest
Regression Analysis: - New regression? Yes - Reproducibility? Yes
Build regression: arm rustgcc unknown argument '-mno-fdpic'
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
## Build log Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic'
## Source * Kernel version: v6.15-rc1 * Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git * Git sha: 0af2f6be1b4281385b618cb86ad946eded089ac8 * Git describe: v6.15-rc1 * Project details: https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.15-rc1/ * compiler: gcc version (Debian 14.2.0-19) 14.2.0 * Toolchain: rustgcc * build config: rustgcc-lkftconfig-kselftest
## Test * Test log: https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.15-rc1/tes... * Test details: https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.15-rc1/tes... * Test history: https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.15-rc1/tes... * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2vNMCPjd4rTR3hQdnzAuH... * Kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/2vNMCPjd4rTR3hQdnzAuH... * Test history on next: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250407/tes...
## Steps to reproduce - tuxmake --runtime podman --target-arch arm --toolchain rustgcc --kconfig defconfig --kconfig-add https://gitlab.com/Linaro/lkft/kernel-fragments/-/raw/main/systemd.config --kconfig-add CONFIG_ARM_LPAE=y --kconfig-add CONFIG_GCC_PLUGINS=n --kconfig-add tools/testing/selftests/rust/config TARGETS=rust dtbs dtbs-legacy headers kernel kselftest modules
-- Linaro LKFT https://lkft.linaro.org
On Mon, 07 Apr 2025 22:58:02 +0530 Naresh Kamboju naresh.kamboju@linaro.org wrote:
Regressions on arm build with config rustgcc-lkftconfig-kselftest on the Linux mainline and next failed with CONFIG_RUST=y enabled.
Bad: next-20250327 Good: next-20250326
Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic'
I assume this is the arm support, i.e. commit ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7").
Clang does not seem to support `-mno-fdpic`, thus you probably need to add it to `bindgen_skip_c_flags` in `rust/Makefile` so that it gets skipped when the C compiler is GCC.
If you do so, please double-check if the flag could potentially alter the ABI in a way that `bindgen` would generate the wrong bindings.
I hope that helps!
Cheers, Miguel
Hey Christian, Miguel,
On Tue, 8 Apr 2025 at 00:07, Miguel Ojeda ojeda@kernel.org wrote:
On Mon, 07 Apr 2025 22:58:02 +0530 Naresh Kamboju naresh.kamboju@linaro.org wrote:
Regressions on arm build with config rustgcc-lkftconfig-kselftest on the Linux mainline and next failed with CONFIG_RUST=y enabled.
Bad: next-20250327 Good: next-20250326
Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic'
I assume this is the arm support, i.e. commit ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7").
Clang does not seem to support `-mno-fdpic`, thus you probably need to add it to `bindgen_skip_c_flags` in `rust/Makefile` so that it gets skipped when the C compiler is GCC.
If you do so, please double-check if the flag could potentially alter the ABI in a way that `bindgen` would generate the wrong bindings.
I tested this idea and it works but I don't know enough about rust to double-check if the flag could potentially alter the ABI in a way that `bindgen` would generate the wrong bindings.
diff --git a/rust/Makefile b/rust/Makefile index 3aca903a7d08..f207ba0ed466 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -273,7 +273,7 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \ -fzero-call-used-regs=% -fno-stack-clash-protection \ -fno-inline-functions-called-once -fsanitize=bounds-strict \ -fstrict-flex-arrays=% -fmin-function-alignment=% \ - -fzero-init-padding-bits=% \ + -fzero-init-padding-bits=% -mno-fdpic \ --param=% --param asan-%
# Derived from `scripts/Makefile.clang`.
- Naresh
I hope that helps!
Cheers, Miguel
On Tue, Apr 15, 2025 at 1:40 PM Naresh Kamboju naresh.kamboju@linaro.org wrote:
On Tue, 8 Apr 2025 at 00:07, Miguel Ojeda ojeda@kernel.org wrote:
On Mon, 07 Apr 2025 22:58:02 +0530 Naresh Kamboju naresh.kamboju@linaro.org wrote:
Regressions on arm build with config rustgcc-lkftconfig-kselftest on the Linux mainline and next failed with CONFIG_RUST=y enabled.
Bad: next-20250327 Good: next-20250326
Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic'
I assume this is the arm support, i.e. commit ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7").
Clang does not seem to support `-mno-fdpic`, thus you probably need to add it to `bindgen_skip_c_flags` in `rust/Makefile` so that it gets skipped when the C compiler is GCC.
If you do so, please double-check if the flag could potentially alter the ABI in a way that `bindgen` would generate the wrong bindings.
I tested this idea and it works but I don't know enough about rust to double-check if the flag could potentially alter the ABI in a way that `bindgen` would generate the wrong bindings.
Yeah, it would be nice to have someone knowledgeable about the arch/GCC/flag confirm or not -- I don't think Rust knowledge is needed, i.e. it is mostly about how GCC behaves with/without the flag and vs. Clang (since `bindgen` uses libclang to parse code).
The original commit adding it to arm (and similar ones for sh and xtensa) says:
When building with an arm-*-uclinuxfdpiceabi toolchain, the FDPIC ABI is enabled by default but should not be used to build the kernel.
So it sounds like it is only an issue for particular toolchains/targets anyway?
Cc'ing Ben who introduced it, and the arm port GCC maintainers in case they may be able to tell us more -- thanks in advance, and sorry for any potential noise!
Cheers, Miguel
On Tue, Apr 15, 2025 at 05:38:54PM +0200, Miguel Ojeda wrote:
On Tue, Apr 15, 2025 at 1:40 PM Naresh Kamboju naresh.kamboju@linaro.org wrote:
On Tue, 8 Apr 2025 at 00:07, Miguel Ojeda ojeda@kernel.org wrote:
On Mon, 07 Apr 2025 22:58:02 +0530 Naresh Kamboju naresh.kamboju@linaro.org wrote:
Regressions on arm build with config rustgcc-lkftconfig-kselftest on the Linux mainline and next failed with CONFIG_RUST=y enabled.
Bad: next-20250327 Good: next-20250326
Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic'
I assume this is the arm support, i.e. commit ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7").
Clang does not seem to support `-mno-fdpic`, thus you probably need to add it to `bindgen_skip_c_flags` in `rust/Makefile` so that it gets skipped when the C compiler is GCC.
If you do so, please double-check if the flag could potentially alter the ABI in a way that `bindgen` would generate the wrong bindings.
I tested this idea and it works but I don't know enough about rust to double-check if the flag could potentially alter the ABI in a way that `bindgen` would generate the wrong bindings.
Yeah, it would be nice to have someone knowledgeable about the arch/GCC/flag confirm or not -- I don't think Rust knowledge is needed, i.e. it is mostly about how GCC behaves with/without the flag and vs. Clang (since `bindgen` uses libclang to parse code).
The original commit adding it to arm (and similar ones for sh and xtensa) says:
When building with an arm-*-uclinuxfdpiceabi toolchain, the FDPIC ABI is enabled by default but should not be used to build the kernel.So it sounds like it is only an issue for particular toolchains/targets anyway?
Cc'ing Ben who introduced it, and the arm port GCC maintainers in case they may be able to tell us more -- thanks in advance, and sorry for any potential noise!
FDPIC is only relevant with no-MMU targets, and then only for userspace. When configured for the arm-*-uclinuxfdpiceabi target, GCC enables FDPIC by default to facilitate compiling userspace programs. FDPIC is never used for the kernel, and we pass -mno-fdpic when building the kernel to override the default and make sure FDPIC is disabled.
Therefore, it is perfectly safe to omit that flag for kernel builds with Clang.
Ben
On Fri, Apr 18, 2025 at 9:44 PM Ben Wolsieffer ben.wolsieffer@hefring.com wrote:
FDPIC is only relevant with no-MMU targets, and then only for userspace. When configured for the arm-*-uclinuxfdpiceabi target, GCC enables FDPIC by default to facilitate compiling userspace programs. FDPIC is never used for the kernel, and we pass -mno-fdpic when building the kernel to override the default and make sure FDPIC is disabled.
Therefore, it is perfectly safe to omit that flag for kernel builds with Clang.
Thanks a lot for the details!
To clarify, this is for GCC kernel builds: skipping the flag is done for libclang under GCC builds (because `bindgen` always uses libclang, and `bindgen` is used by Rust to understand C headers).
So GCC will get the flag for the C side of the kernel builds, but libclang will not get the flag because Clang doesn't recognize it. Thus, if Clang vs. GCC differ in how they compute the layout of some type, then we would have an issue "mixing" them.
As you can imagine, GCC kernel builds with Rust enabled are a hack due to that, and it would be ideal to get `bindgen` to somehow be able to understand C headers as GCC does:
https://github.com/rust-lang/rust-bindgen/issues/1949
Cheers, Miguel
On Sat, Apr 19, 2025 at 12:30:01AM +0200, Miguel Ojeda wrote:
Thanks a lot for the details!
To clarify, this is for GCC kernel builds: skipping the flag is done for libclang under GCC builds (because `bindgen` always uses libclang, and `bindgen` is used by Rust to understand C headers).
So GCC will get the flag for the C side of the kernel builds, but libclang will not get the flag because Clang doesn't recognize it. Thus, if Clang vs. GCC differ in how they compute the layout of some type, then we would have an issue "mixing" them.
As you can imagine, GCC kernel builds with Rust enabled are a hack due to that, and it would be ideal to get `bindgen` to somehow be able to understand C headers as GCC does:
https://github.com/rust-lang/rust-bindgen/issues/1949
-mno-fdpic disables a GCC feature that we don't want for kernel builds. clang does not support this feature, so it always behaves as though -mno-fdpic is passed. Therefore, it should be fine to mix the two, at least as far as FDPIC is concerned.
Ben
On Thu, Apr 24, 2025 at 3:39 PM Ben Wolsieffer ben.wolsieffer@hefring.com wrote:
-mno-fdpic disables a GCC feature that we don't want for kernel builds. clang does not support this feature, so it always behaves as though -mno-fdpic is passed. Therefore, it should be fine to mix the two, at least as far as FDPIC is concerned.
Great, thanks a lot for confirming it should be all good, very much appreciated!
Naresh: would you like to send the diff as a formal patch since you already tested it etc.?
Cheers, Miguel
Naresh: would you like to send the diff as a formal patch since you already tested it etc.?
Hello Miguel and Naresh,
I went ahead and sent a patch to Linus directly since it seemed to me that this was about to fall thru the cracks. I signed both you and Naresh on it since it seemed like you both were happy with the small patch. Apologies if that's not standard, please do correct me as I'm still new to kernel development.
Btw Miguel, thanks for introducing Rust to Linux. I'm not too good at kernel development or Rust, but hope to one day. The modern Zulip board and documentation is very nice for newbies like me. Looking forward to making my first Linux driver and Rust driver soon. :)
Thanks,
Rudraksha
On Wed, May 21, 2025 at 1:21 AM Rudraksha Gupta guptarud@gmail.com wrote:
I went ahead and sent a patch to Linus directly since it seemed to me that this was about to fall thru the cracks. I signed both you and Naresh on it since it seemed like you both were happy with the small patch. Apologies if that's not standard, please do correct me as I'm still new to kernel development.
Yeah, it is not standard, but no worries -- I will reply there.
Btw Miguel, thanks for introducing Rust to Linux. I'm not too good at kernel development or Rust, but hope to one day. The modern Zulip board and documentation is very nice for newbies like me. Looking forward to making my first Linux driver and Rust driver soon. :)
Thanks for the kind words! :)
Cheers, Miguel
-
Ben Wolsieffer -
Miguel Ojeda -
Miguel Ojeda -
Naresh Kamboju -
Rudraksha Gupta