RISC-V: Re-enable GCC+Rust builds

RISC-V: Re-enable GCC+Rust builds

[Asuna Yang]

I noticed that GCC+Rust builds for RISC-V were disabled about a year 
ago, as discussed in
https://lore.kernel.org/all/20240917000848.720765-1-jmontleo@redhat.com/

I'm a bit lost here. What are the main obstacles to re-enabling GCC 
builds now?

Conor said:
 > Okay. Short term then is deny gcc + rust, longer term is allow it 
with the same caveats as the aforementioned mixed stuff.
"the same caveats" means detecting what specifically?

We have a RISC-V PWM driver being written in Rust. Currently, GCC being 
disabled for building the kernel with Rust for RISC-V is the primary 
blocker for including these drivers in RISC-V distros. Therefore, I'd 
like to push forward and contribute to the re-enabling of GCC builds. Is 
there a more detailed direction on what I can do here?

Thanks.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: RISC-V: Re-enable GCC+Rust builds

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 1987 bytes --]

On Sat, Aug 30, 2025 at 01:00:56PM +0800, Asuna Yang wrote:
> I noticed that GCC+Rust builds for RISC-V were disabled about a year ago, as
> discussed in
> https://lore.kernel.org/all/20240917000848.720765-1-jmontleo@redhat.com/
> 
> I'm a bit lost here. What are the main obstacles to re-enabling GCC builds
> now?
> 
> Conor said:
> > Okay. Short term then is deny gcc + rust, longer term is allow it with the
> same caveats as the aforementioned mixed stuff.
> "the same caveats" means detecting what specifically?

There's "code" in the riscv Kconfig/Makefile that makes sure that the
assembler has the same understanding of what extensions are enabled as
the compiler. This is done by detecting which version of the tools are
in use, and adjusting march etc as a result. See
TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI for an example. When I wrote the
comment you're citing, there was no "off the shelf" way to figure out
the version of libclang in use to ensure that it has the same
understanding of -march as the version of gcc being used on the c side
does. For clang build, it's not a concern since it's almost certainly
the exact same as the compiler building the c side.

> We have a RISC-V PWM driver being written in Rust. Currently, GCC being
> disabled for building the kernel with Rust for RISC-V is the primary blocker
> for including these drivers in RISC-V distros. Therefore, I'd like to push
> forward and contribute to the re-enabling of GCC builds. Is there a more
> detailed direction on what I can do here?

Add the version of libclang as a Kconfig symbol, so that the kernel's
build system can ensure that both sides are built using the same
configuration. Off the top of my head, using a pre-17 libclang with a
new gcc would require having zicsr in -march for the c side and it
removed for rust. It's been a while (1 year+) since I fiddled with this
though, so my recollection there could well be inaccurate.

Cheers,
Conor.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: RISC-V: Re-enable GCC+Rust builds

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2751 bytes --]

On Sat, Aug 30, 2025 at 07:17:48PM +0100, Conor Dooley wrote:
> On Sat, Aug 30, 2025 at 01:00:56PM +0800, Asuna Yang wrote:
> > I noticed that GCC+Rust builds for RISC-V were disabled about a year ago, as
> > discussed in
> > https://lore.kernel.org/all/20240917000848.720765-1-jmontleo@redhat.com/
> > 
> > I'm a bit lost here. What are the main obstacles to re-enabling GCC builds
> > now?
> > 
> > Conor said:
> > > Okay. Short term then is deny gcc + rust, longer term is allow it with the
> > same caveats as the aforementioned mixed stuff.
> > "the same caveats" means detecting what specifically?
> 
> There's "code" in the riscv Kconfig/Makefile that makes sure that the
> assembler has the same understanding of what extensions are enabled as
> the compiler. This is done by detecting which version of the tools are
> in use, and adjusting march etc as a result. See
> TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI for an example. When I wrote the
> comment you're citing, there was no "off the shelf" way to figure out
> the version of libclang in use to ensure that it has the same
> understanding of -march as the version of gcc being used on the c side
> does. For clang build, it's not a concern since it's almost certainly
> the exact same as the compiler building the c side.
> 
> > We have a RISC-V PWM driver being written in Rust. Currently, GCC being
> > disabled for building the kernel with Rust for RISC-V is the primary blocker
> > for including these drivers in RISC-V distros. Therefore, I'd like to push
> > forward and contribute to the re-enabling of GCC builds. Is there a more
> > detailed direction on what I can do here?
> 
> Add the version of libclang as a Kconfig symbol, so that the kernel's
> build system can ensure that both sides are built using the same
> configuration. Off the top of my head, using a pre-17 libclang with a
> new gcc would require having zicsr in -march for the c side and it
> removed for rust. It's been a while (1 year+) since I fiddled with this
> though, so my recollection there could well be inaccurate.

Hmm, while I think of it, there's some other things that are problematic
that are not currently checked but would have to be. For example,
there's a check in the riscv Kconfig menu to see if
stack-protector-guard=tls can be used via a cc-option check. If that
check passes with gcc as the compiler that option will be passed to the
rust side of the build, where llvm might not support it.
Similarly, turning on an extension like Zacas via a cc-option check could
pass for gcc but not be usable when passed to the rust side, causing
errors. These sorts of things should be prevented via Kconfig, not show
up as confusing build errors.


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: RISC-V: Re-enable GCC+Rust builds

[Asuna]

> For example, there's a check in the riscv Kconfig menu to see if 
> stack-protector-guard=tls can be used via a cc-option check. If that 
> check passes with gcc as the compiler that option will be passed to 
> the rust side of the build, where llvm might not support it.
If I understand correctly, the `-mstack-protector-guard` option is 
already always filtered out by `bindgen_skip_c_flags` in 
`rust/Makefile`, regardless of architecture. Therefore, we don't need to 
do anything more, right?

> Similarly, turning on an extension like Zacas via a cc-option check 
> could pass for gcc but not be usable when passed to the rust side, 
> causing errors.
That makes sense. I might need to check the version of libclang for each 
extension that passes the cc-option check for GCC to ensure it supports 
them.

> These sorts of things should be prevented via Kconfig, not show up as 
> confusing build errors.
I'm working on a patch, and intend to output an error message in 
`arch/riscv/Makefile` then exit 1 when detecting an incompatible 
gcc+libclang mix in use.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: RISC-V: Re-enable GCC+Rust builds

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2412 bytes --]

On Tue, Sep 02, 2025 at 01:19:42AM +0800, Asuna wrote:
> > For example, there's a check in the riscv Kconfig menu to see if
> > stack-protector-guard=tls can be used via a cc-option check. If that
> > check passes with gcc as the compiler that option will be passed to the
> > rust side of the build, where llvm might not support it.
> If I understand correctly, the `-mstack-protector-guard` option is already
> always filtered out by `bindgen_skip_c_flags` in `rust/Makefile`, regardless
> of architecture. Therefore, we don't need to do anything more, right?

That particular one might be a problem not because of
-mstack-protector-guard itself, but rather three options get added at
once:
	$(eval KBUILD_CFLAGS += -mstack-protector-guard=tls		  \
				-mstack-protector-guard-reg=tp		  \
				-mstack-protector-guard-offset=$(shell	  \
			awk '{if ($$2 == "TSK_STACK_CANARY") print $$3;}' \
				$(objtree)/include/generated/asm-offsets.h))
and the other ones might be responsible for the error.
Similarly, something like -Wno-unterminated-string-initialization could
cause a problem if gcc supports it but not libclang.

I was doing some debugging today of another problem, and was able to
trigger both of those errors with llvm-21 and libclang-19, so they
definitely have the potential to be problems if there's a mismatch - I
just don't know how many of those issues affect a mixed build with rustc
and the gnu tools, mixing llvm and libclang versions already produces
a warning about it being a Bad IdeaTM (a warning that I think should be
an error).

> > Similarly, turning on an extension like Zacas via a cc-option check
> > could pass for gcc but not be usable when passed to the rust side,
> > causing errors.
> That makes sense. I might need to check the version of libclang for each
> extension that passes the cc-option check for GCC to ensure it supports
> them.
> 
> > These sorts of things should be prevented via Kconfig, not show up as
> > confusing build errors.
> I'm working on a patch, and intend to output an error message in
> `arch/riscv/Makefile` then exit 1 when detecting an incompatible
> gcc+libclang mix in use.

I think you're mostly better off catching that sort of thing in Kconfig,
where possible and just make incompatible mixes invalid. What's actually
incompatible is likely going to depend heavily on what options are
enabled.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: RISC-V: Re-enable GCC+Rust builds

[Asuna]

> That particular one might be a problem not because of -mstack-protector-guard itself, but rather three options get added at once:
> 	$(eval KBUILD_CFLAGS += -mstack-protector-guard=tls		  \
> 				-mstack-protector-guard-reg=tp		  \
> 				-mstack-protector-guard-offset=$(shell	  \
> 			awk '{if ($$2 == "TSK_STACK_CANARY") print $$3;}' \
> 				$(objtree)/include/generated/asm-offsets.h))
> and the other ones might be responsible for the error.


I still don't understand the problem here. `bindgen_skip_c_flags` in 
`rust/Makefile` contains a pattern `-mstack-protector-guard%`, the % at 
the end enables it to match all those 3 options at the same time, and 
`filter-out` function removes them before passing to Rust bindgen's 
libclang. Am I missing something here?


> Similarly, something like -Wno-unterminated-string-initialization could cause a problem if gcc supports it but not libclang.


Yes. However, this option is only about warnings, not architecture 
related and does not affect the generated results, so simply adding it 
into `bindgen_skip_c_flags` patterns should be enough, I think.

> I think you're mostly better off catching that sort of thing in Kconfig, where possible and just make incompatible mixes invalid. What's actually incompatible is likely going to depend heavily on what options are enabled.

Sounds better, I'll go down that path.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: RISC-V: Re-enable GCC+Rust builds

[Asuna]

(I apologize if anyone gets this email twice, the first time I 
mistakenly sent it as HTML and it was rejected by mailing lists)

> Similarly, something like -Wno-unterminated-string-initialization could
> cause a problem if gcc supports it but not libclang.
And the -Wno-unterminated-string-initialization is not supposed to be a 
problem either, today I noticed that in rust/Makefile there is:

    # All warnings are inhibited since GCC builds are very experimental,
    # many GCC warnings are not supported by Clang, they may only appear in
    # some configurations, with new GCC versions, etc.
    bindgen_extra_c_flags = -w --target=$(BINDGEN_TARGET)

The -w flag inhibits all warnings, even though Clang may not recognize 
it. I was not able to reproduce any errors related to this.

I have a patch ready and will send it later. Please let me know if I'm 
missing something there. Thanks.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script

[Asuna Yang]

Decouple the code for getting the version of libclang used by Rust
bindgen from rust_is_available.sh into a separate script so that we can
define a symbol for the version in Kconfig that will be used for
checking in subsequent patches.

Signed-off-by: Asuna Yang <SpriteOvO@gmail.com>
---
 init/Kconfig                                  |  6 ++
 rust/Makefile                                 |  2 +-
 scripts/Kconfig.include                       |  1 +
 ...lang.h => rust-bindgen-libclang-version.h} |  0
 scripts/rust-bindgen-libclang-version.sh      | 94 +++++++++++++++++++
 scripts/rust_is_available.sh                  | 58 +++---------
 scripts/rust_is_available_test.py             | 22 ++---
 7 files changed, 125 insertions(+), 58 deletions(-)
 rename scripts/{rust_is_available_bindgen_libclang.h => rust-bindgen-libclang-version.h} (100%)
 create mode 100755 scripts/rust-bindgen-libclang-version.sh

diff --git a/init/Kconfig b/init/Kconfig
index 666783eb50ab..322af2ba76cd 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -82,6 +82,12 @@ config RUSTC_LLVM_VERSION
 	int
 	default $(rustc-llvm-version)
 
+config RUST_BINDGEN_LIBCLANG_VERSION
+	int
+	default $(rustc-bindgen-libclang-version)
+	help
+	  This is the version of `libclang` used by the Rust bindings generator.
+
 config CC_CAN_LINK
 	bool
 	default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(USERCFLAGS) $(USERLDFLAGS) $(m64-flag)) if 64BIT
diff --git a/rust/Makefile b/rust/Makefile
index 115b63b7d1e3..34d0429d50fd 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -300,7 +300,7 @@ bindgen_extra_c_flags = -w --target=$(BINDGEN_TARGET)
 # https://github.com/llvm/llvm-project/issues/44842
 # https://github.com/llvm/llvm-project/blob/llvmorg-16.0.0-rc2/clang/docs/ReleaseNotes.rst#deprecated-compiler-flags
 ifdef CONFIG_INIT_STACK_ALL_ZERO
-libclang_maj_ver=$(shell $(BINDGEN) $(srctree)/scripts/rust_is_available_bindgen_libclang.h 2>&1 | sed -ne 's/.*clang version \([0-9]*\).*/\1/p')
+libclang_maj_ver=$(shell $(srctree)/scripts/rust-bindgen-libclang-version.sh --with-non-canonical $(BINDGEN) | sed -ne '2s/\([0-9]*\).*/\1/p')
 ifeq ($(shell expr $(libclang_maj_ver) \< 16), 1)
 bindgen_extra_c_flags += -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
 endif
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 33193ca6e803..68df1fed69a1 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -67,6 +67,7 @@ m64-flag := $(cc-option-bit,-m64)
 
 rustc-version := $(shell,$(srctree)/scripts/rustc-version.sh $(RUSTC))
 rustc-llvm-version := $(shell,$(srctree)/scripts/rustc-llvm-version.sh $(RUSTC))
+rustc-bindgen-libclang-version := $(shell,$(srctree)/scripts/rust-bindgen-libclang-version.sh $(BINDGEN) 2>/dev/null)
 
 # $(rustc-option,<flag>)
 # Return y if the Rust compiler supports <flag>, n otherwise
diff --git a/scripts/rust_is_available_bindgen_libclang.h b/scripts/rust-bindgen-libclang-version.h
similarity index 100%
rename from scripts/rust_is_available_bindgen_libclang.h
rename to scripts/rust-bindgen-libclang-version.h
diff --git a/scripts/rust-bindgen-libclang-version.sh b/scripts/rust-bindgen-libclang-version.sh
new file mode 100755
index 000000000000..45485d0f95c8
--- /dev/null
+++ b/scripts/rust-bindgen-libclang-version.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Print the version of `libclang` used by the Rust bindings generator in a 5 or 6-digit form,
+# and a non-canonical form if `--with-non-canonical` option is specified.
+# Also, perform the minimum version check.
+
+set -e
+
+# If the script fails, print 0 to stdout as the version output.
+trap 'if [ $? -ne 0 ]; then echo 0; fi' EXIT
+
+while [ $# -gt 0 ]; do
+	case "$1" in
+	--with-non-canonical)
+		with_non_canonical=1
+		;;
+	-*)
+		echo >&2 "Unknown option: $1"
+		exit 1
+		;;
+	*)
+		break
+		;;
+	esac
+	shift
+done
+
+get_bindgen_libclang_version()
+{
+	# Invoke `bindgen` to get the `libclang` version found by `bindgen`. This step
+	# may already fail if, for instance, `libclang` is not found, thus inform the
+	# user in such a case.
+	output=$( \
+		LC_ALL=C "$@" $(dirname $0)/rust-bindgen-libclang-version.h 2>&1 >/dev/null
+	) || code=$?
+	if [ -n "$code" ]; then
+		echo >&2 "***"
+		echo >&2 "*** Running '$@' to check the libclang version (used by the Rust"
+		echo >&2 "*** bindings generator) failed with code $code. This may be caused by"
+		echo >&2 "*** a failure to locate libclang. See output and docs below for details:"
+		echo >&2 "***"
+		echo >&2 "$output"
+		echo >&2 "***"
+		exit 1
+	fi
+
+	# Unlike other version checks, note that this one does not necessarily appear
+	# in the first line of the output, thus no `sed` address is provided.
+	version=$( \
+		echo "$output" \
+			| sed -nE 's:.*clang version ([0-9]+\.[0-9]+\.[0-9]+).*:\1:p'
+	)
+	if [ -z "$version" ]; then
+		echo >&2 "***"
+		echo >&2 "*** Running '$@' to check the libclang version (used by the Rust"
+		echo >&2 "*** bindings generator) did not return an expected output. See output"
+		echo >&2 "*** and docs below for details:"
+		echo >&2 "***"
+		echo >&2 "$output"
+		echo >&2 "***"
+		exit 1
+	fi
+	echo "$version"
+}
+
+# Convert the version string x.y.z to a canonical 5 or 6-digit form.
+get_canonical_version()
+{
+	IFS=.
+	set -- $1
+	echo $((10000 * $1 + 100 * $2 + $3))
+}
+
+min_tool_version=$(dirname $0)/min-tool-version.sh
+
+version=$(get_bindgen_libclang_version "$@")
+min_version=$($min_tool_version llvm)
+cversion=$(get_canonical_version $version)
+min_cversion=$(get_canonical_version $min_version)
+
+if [ "$cversion" -lt "$min_cversion" ]; then
+	echo >&2 "***"
+	echo >&2 "*** libclang (used by the Rust bindings generator '$@') is too old."
+	echo >&2 "***   Your version:    $version"
+	echo >&2 "***   Minimum version: $min_version"
+	echo >&2 "***"
+	exit 1
+fi
+
+echo "$cversion"
+if [ -n "$with_non_canonical" ]; then
+	echo "$version"
+fi
diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
index d2323de0692c..ccbd5efe9498 100755
--- a/scripts/rust_is_available.sh
+++ b/scripts/rust_is_available.sh
@@ -179,55 +179,21 @@ fi
 
 # Check that the `libclang` used by the Rust bindings generator is suitable.
 #
-# In order to do that, first invoke `bindgen` to get the `libclang` version
-# found by `bindgen`. This step may already fail if, for instance, `libclang`
-# is not found, thus inform the user in such a case.
-bindgen_libclang_output=$( \
-	LC_ALL=C "$BINDGEN" $(dirname $0)/rust_is_available_bindgen_libclang.h 2>&1 >/dev/null
-) || bindgen_libclang_code=$?
-if [ -n "$bindgen_libclang_code" ]; then
-	echo >&2 "***"
-	echo >&2 "*** Running '$BINDGEN' to check the libclang version (used by the Rust"
-	echo >&2 "*** bindings generator) failed with code $bindgen_libclang_code. This may be caused by"
-	echo >&2 "*** a failure to locate libclang. See output and docs below for details:"
-	echo >&2 "***"
-	echo >&2 "$bindgen_libclang_output"
-	echo >&2 "***"
-	exit 1
-fi
-
-# `bindgen` returned successfully, thus use the output to check that the version
-# of the `libclang` found by the Rust bindings generator is suitable.
-#
-# Unlike other version checks, note that this one does not necessarily appear
-# in the first line of the output, thus no `sed` address is provided.
-bindgen_libclang_version=$( \
-	echo "$bindgen_libclang_output" \
-		| sed -nE 's:.*clang version ([0-9]+\.[0-9]+\.[0-9]+).*:\1:p'
-)
-if [ -z "$bindgen_libclang_version" ]; then
-	echo >&2 "***"
-	echo >&2 "*** Running '$BINDGEN' to check the libclang version (used by the Rust"
-	echo >&2 "*** bindings generator) did not return an expected output. See output"
-	echo >&2 "*** and docs below for details:"
-	echo >&2 "***"
-	echo >&2 "$bindgen_libclang_output"
-	echo >&2 "***"
-	exit 1
-fi
-bindgen_libclang_min_version=$($min_tool_version llvm)
-bindgen_libclang_cversion=$(get_canonical_version $bindgen_libclang_version)
-bindgen_libclang_min_cversion=$(get_canonical_version $bindgen_libclang_min_version)
-if [ "$bindgen_libclang_cversion" -lt "$bindgen_libclang_min_cversion" ]; then
-	echo >&2 "***"
-	echo >&2 "*** libclang (used by the Rust bindings generator '$BINDGEN') is too old."
-	echo >&2 "***   Your version:    $bindgen_libclang_version"
-	echo >&2 "***   Minimum version: $bindgen_libclang_min_version"
-	echo >&2 "***"
+# Get the version, and the minimum version check will be performed internally.
+bindgen_libclang_version_output=$( \
+	$(dirname $0)/rust-bindgen-libclang-version.sh --with-non-canonical $BINDGEN
+) || bindgen_libclang_version_code=$?
+if [ -n "$bindgen_libclang_version_code" ]; then
+	# Detailed error messages have already been output in the script we just called.
 	exit 1
 fi
 
-if [ "$bindgen_libclang_cversion" -ge 1900100 ] &&
+# Getting the version successfully, thus use the output to check that the
+# version of the `libclang` found by the Rust bindings generator is suitable.
+readarray -t bindgen_libclang_version_array <<<"$bindgen_libclang_version_output"
+bindgen_libclang_version=${bindgen_libclang_version_array[1]}
+bindgen_libclang_cversion=${bindgen_libclang_version_array[0]}
+if [ "$bindgen_libclang_cversion" -ge 190100 ] &&
 	[ "$rust_bindings_generator_cversion" -lt 6905 ]; then
 	# Distributions may have patched the issue (e.g. Debian did).
 	if ! "$BINDGEN" $(dirname $0)/rust_is_available_bindgen_libclang_concat.h | grep -q foofoo; then
diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
index 4fcc319dea84..b7265e2691cf 100755
--- a/scripts/rust_is_available_test.py
+++ b/scripts/rust_is_available_test.py
@@ -72,7 +72,7 @@ else:
 
         return cls.generate_executable(f"""#!/usr/bin/env python3
 import sys
-if "rust_is_available_bindgen_libclang.h" in " ".join(sys.argv):
+if "rust-bindgen-libclang-version.h" in " ".join(sys.argv):
     {libclang_case}
 elif "rust_is_available_bindgen_0_66.h" in " ".join(sys.argv):
     {version_0_66_case}
@@ -113,7 +113,7 @@ else:
 
         cls.bindgen_default_bindgen_version_stdout = f"bindgen {cls.bindgen_default_version}"
         cls.bindgen_default_bindgen_libclang_failure_exit_code = 42
-        cls.bindgen_default_bindgen_libclang_stderr = f"scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version {cls.llvm_default_version} [-W#pragma-messages], err: false"
+        cls.bindgen_default_bindgen_libclang_stderr = f"scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version {cls.llvm_default_version} [-W#pragma-messages], err: false"
 
         cls.default_rustc = cls.generate_rustc(f"rustc {cls.rustc_default_version}")
         cls.default_bindgen =  cls.generate_bindgen(cls.bindgen_default_bindgen_version_stdout, cls.bindgen_default_bindgen_libclang_stderr)
@@ -265,13 +265,13 @@ else:
         self.assertIn(f"bindings generator) failed with code {self.bindgen_default_bindgen_libclang_failure_exit_code}. This may be caused by", result.stderr)
 
     def test_bindgen_libclang_unexpected_version(self):
-        bindgen = self.generate_bindgen_libclang("scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version unexpected [-W#pragma-messages], err: false")
+        bindgen = self.generate_bindgen_libclang("scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version unexpected [-W#pragma-messages], err: false")
         result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
         self.assertIn(f"Running '{bindgen}' to check the libclang version (used by the Rust", result.stderr)
         self.assertIn("bindings generator) did not return an expected output. See output", result.stderr)
 
     def test_bindgen_libclang_old_version(self):
-        bindgen = self.generate_bindgen_libclang("scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version 10.0.0 [-W#pragma-messages], err: false")
+        bindgen = self.generate_bindgen_libclang("scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version 10.0.0 [-W#pragma-messages], err: false")
         result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
         self.assertIn(f"libclang (used by the Rust bindings generator '{bindgen}') is too old.", result.stderr)
 
@@ -291,7 +291,7 @@ else:
         ):
             with self.subTest(bindgen_version=bindgen_version, libclang_version=libclang_version):
                 cc = self.generate_clang(f"clang version {libclang_version}")
-                libclang_stderr = f"scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version {libclang_version} [-W#pragma-messages], err: false"
+                libclang_stderr = f"scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version {libclang_version} [-W#pragma-messages], err: false"
                 bindgen = self.generate_bindgen(f"bindgen {bindgen_version}", libclang_stderr)
                 result = self.run_script(expected_not_patched, { "BINDGEN": bindgen, "CC": cc })
                 if expected_not_patched == self.Expected.SUCCESS_WITH_WARNINGS:
@@ -301,7 +301,7 @@ else:
                 result = self.run_script(self.Expected.SUCCESS, { "BINDGEN": bindgen, "CC": cc })
 
     def test_clang_matches_bindgen_libclang_different_bindgen(self):
-        bindgen = self.generate_bindgen_libclang("scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version 999.0.0 [-W#pragma-messages], err: false")
+        bindgen = self.generate_bindgen_libclang("scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version 999.0.0 [-W#pragma-messages], err: false")
         result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
         self.assertIn("version does not match Clang's. This may be a problem.", result.stderr)
 
@@ -352,16 +352,16 @@ InstalledDir: /usr/bin
 
     def test_success_bindgen_libclang(self):
         for stderr in (
-            f"scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version {self.llvm_default_version} (https://github.com/llvm/llvm-project.git 4a2c05b05ed07f1f620e94f6524a8b4b2760a0b1) [-W#pragma-messages], err: false",
-            f"/home/jd/Documents/dev/kernel-module-flake/linux-6.1/outputs/dev/lib/modules/6.1.0-development/source/scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version {self.llvm_default_version}  [-W#pragma-messages], err: false",
-            f"scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version {self.llvm_default_version} (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false",
+            f"scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version {self.llvm_default_version} (https://github.com/llvm/llvm-project.git 4a2c05b05ed07f1f620e94f6524a8b4b2760a0b1) [-W#pragma-messages], err: false",
+            f"/home/jd/Documents/dev/kernel-module-flake/linux-6.1/outputs/dev/lib/modules/6.1.0-development/source/scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version {self.llvm_default_version}  [-W#pragma-messages], err: false",
+            f"scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version {self.llvm_default_version} (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false",
             f"""
 /nix/store/dsd5gz46hdbdk2rfdimqddhq6m8m8fqs-bash-5.1-p16/bin/bash: warning: setlocale: LC_ALL: cannot change locale (c)
-scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version {self.llvm_default_version}  [-W#pragma-messages], err: false
+scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version {self.llvm_default_version}  [-W#pragma-messages], err: false
 """,
             f"""
 /nix/store/dsd5gz46hdbdk2rfdimqddhq6m8m8fqs-bash-5.1.0-p16/bin/bash: warning: setlocale: LC_ALL: cannot change locale (c)
-/home/jd/Documents/dev/kernel-module-flake/linux-6.1/outputs/dev/lib/modules/6.1.0-development/source/scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version {self.llvm_default_version} (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false
+/home/jd/Documents/dev/kernel-module-flake/linux-6.1/outputs/dev/lib/modules/6.1.0-development/source/scripts/rust-bindgen-libclang-version.h:2:9: warning: clang version {self.llvm_default_version} (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false
 """
         ):
             with self.subTest(stderr=stderr):
-- 
2.51.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 2/2] RISC-V: re-enable gcc + rust builds

[Asuna Yang]

Commit 33549fcf37ec ("RISC-V: disallow gcc + rust builds") disabled GCC
+ Rust builds for RISC-V due to differences in extension handling
compared to LLVM.

Add a Kconfig non-visible symbol to ensure that all important RISC-V
specific flags that will be used by GCC can be correctly recognized by
Rust bindgen's libclang, otherwise config HAVE_RUST will not be
selected.

Signed-off-by: Asuna Yang <SpriteOvO@gmail.com>
---
 Documentation/rust/arch-support.rst |  2 +-
 arch/riscv/Kconfig                  | 62 ++++++++++++++++++++++++++++-
 rust/Makefile                       |  7 +++-
 3 files changed, 68 insertions(+), 3 deletions(-)

diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
index 6e6a515d0899..5282e0e174e8 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -18,7 +18,7 @@ Architecture   Level of support  Constraints
 ``arm``        Maintained        ARMv7 Little Endian only.
 ``arm64``      Maintained        Little Endian only.
 ``loongarch``  Maintained        \-
-``riscv``      Maintained        ``riscv64`` and LLVM/Clang only.
+``riscv``      Maintained        ``riscv64`` only.
 ``um``         Maintained        \-
 ``x86``        Maintained        ``x86_64`` only.
 =============  ================  ==============================================
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 1c5544401530..d7f421e0f429 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -195,7 +195,7 @@ config RISCV
 	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_RETHOOK if !XIP_KERNEL
 	select HAVE_RSEQ
-	select HAVE_RUST if RUSTC_SUPPORTS_RISCV && CC_IS_CLANG
+	select HAVE_RUST if RUSTC_SUPPORTS_RISCV && RUST_BINDGEN_LIBCLANG_RECOGNIZES_FLAGS
 	select HAVE_SAMPLE_FTRACE_DIRECT
 	select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
 	select HAVE_STACKPROTECTOR
@@ -236,6 +236,27 @@ config RUSTC_SUPPORTS_RISCV
 	# -Zsanitizer=shadow-call-stack flag.
 	depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108200
 
+config RUST_BINDGEN_LIBCLANG_RECOGNIZES_FLAGS
+	def_bool y
+	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_V
+	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZABHA
+	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZACAS
+	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBA
+	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBB
+	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBC
+	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBKB
+	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZICSR_ZIFENCEI
+	help
+	  Rust bindgen currently relies on libclang as backend. When a mixed build is
+	  performed (building C code with GCC), GCC flags will be passed to libclang.
+	  However, not all GCC flags are recognized by Clang, so most of the
+	  incompatible flags have been filtered out in rust/Makefile.
+
+	  For RISC-V, GCC and Clang are not at the same pace of implementing extensions.
+	  This config ensures that all important RISC-V specific flags that will be
+	  used by GCC can be correctly recognized by Rust bindgen's libclang, otherwise
+	  config HAVE_RUST will not be selected.
+
 config CLANG_SUPPORTS_DYNAMIC_FTRACE
 	def_bool CC_IS_CLANG
 	# https://github.com/ClangBuiltLinux/linux/issues/1817
@@ -634,6 +655,11 @@ config TOOLCHAIN_HAS_V
 	depends on LLD_VERSION >= 140000 || LD_VERSION >= 23800
 	depends on AS_HAS_OPTION_ARCH
 
+config RUST_BINDGEN_LIBCLANG_RECOGNIZES_V
+	def_bool y
+	# https://github.com/llvm/llvm-project/commit/e6de53b4de4aecca4ac892500a0907805896ed27
+	depends on !TOOLCHAIN_HAS_V || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
+
 config RISCV_ISA_V
 	bool "Vector extension support"
 	depends on TOOLCHAIN_HAS_V
@@ -698,6 +724,11 @@ config TOOLCHAIN_HAS_ZABHA
 	depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zabha)
 	depends on AS_HAS_OPTION_ARCH
 
+config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZABHA
+	def_bool y
+	# https://github.com/llvm/llvm-project/commit/6b7444964a8d028989beee554a1f5c61d16a1cac
+	depends on !TOOLCHAIN_HAS_ZABHA || RUST_BINDGEN_LIBCLANG_VERSION >= 190100
+
 config RISCV_ISA_ZABHA
 	bool "Zabha extension support for atomic byte/halfword operations"
 	depends on TOOLCHAIN_HAS_ZABHA
@@ -716,6 +747,11 @@ config TOOLCHAIN_HAS_ZACAS
 	depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zacas)
 	depends on AS_HAS_OPTION_ARCH
 
+config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZACAS
+	def_bool y
+	# https://github.com/llvm/llvm-project/commit/614aeda93b2225c6eb42b00ba189ba7ca2585c60
+	depends on !TOOLCHAIN_HAS_ZACAS || RUST_BINDGEN_LIBCLANG_VERSION >= 200100
+
 config RISCV_ISA_ZACAS
 	bool "Zacas extension support for atomic CAS"
 	depends on TOOLCHAIN_HAS_ZACAS
@@ -735,6 +771,11 @@ config TOOLCHAIN_HAS_ZBB
 	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
 	depends on AS_HAS_OPTION_ARCH
 
+config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBB
+	def_bool y
+	# https://github.com/llvm/llvm-project/commit/33d008b169f3c813a4a45da220d0952f795ac477
+	depends on !TOOLCHAIN_HAS_ZBB || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
+
 # This symbol indicates that the toolchain supports all v1.0 vector crypto
 # extensions, including Zvk*, Zvbb, and Zvbc.  LLVM added all of these at once.
 # binutils added all except Zvkb, then added Zvkb.  So we just check for Zvkb.
@@ -750,6 +791,11 @@ config TOOLCHAIN_HAS_ZBA
 	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
 	depends on AS_HAS_OPTION_ARCH
 
+config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBA
+	def_bool y
+	# https://github.com/llvm/llvm-project/commit/33d008b169f3c813a4a45da220d0952f795ac477
+	depends on !TOOLCHAIN_HAS_ZBA || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
+
 config RISCV_ISA_ZBA
 	bool "Zba extension support for bit manipulation instructions"
 	default y
@@ -785,6 +831,11 @@ config TOOLCHAIN_HAS_ZBC
 	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
 	depends on AS_HAS_OPTION_ARCH
 
+config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBC
+	def_bool y
+	# https://github.com/llvm/llvm-project/commit/33d008b169f3c813a4a45da220d0952f795ac477
+	depends on !TOOLCHAIN_HAS_ZBC || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
+
 config RISCV_ISA_ZBC
 	bool "Zbc extension support for carry-less multiplication instructions"
 	depends on TOOLCHAIN_HAS_ZBC
@@ -808,6 +859,11 @@ config TOOLCHAIN_HAS_ZBKB
 	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
 	depends on AS_HAS_OPTION_ARCH
 
+config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBKB
+	def_bool y
+	# https://github.com/llvm/llvm-project/commit/7ee1c162cc53d37f717f9a138276ad64fa6863bc
+	depends on !TOOLCHAIN_HAS_ZBKB || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
+
 config RISCV_ISA_ZBKB
 	bool "Zbkb extension support for bit manipulation instructions"
 	depends on TOOLCHAIN_HAS_ZBKB
@@ -894,6 +950,10 @@ config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
 	  versions of clang and GCC to be passed to GAS, which has the same result
 	  as passing zicsr and zifencei to -march.
 
+config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZICSR_ZIFENCEI
+	def_bool y
+	depends on TOOLCHAIN_NEEDS_OLD_ISA_SPEC || (TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI && RUST_BINDGEN_LIBCLANG_VERSION >= 170000)
+
 config FPU
 	bool "FPU support"
 	default y
diff --git a/rust/Makefile b/rust/Makefile
index 34d0429d50fd..7b1055c98146 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -277,20 +277,25 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \
 	-fno-inline-functions-called-once -fsanitize=bounds-strict \
 	-fstrict-flex-arrays=% -fmin-function-alignment=% \
 	-fzero-init-padding-bits=% -mno-fdpic \
-	--param=% --param asan-%
+	--param=% --param asan-% -mno-riscv-attribute
 
 # Derived from `scripts/Makefile.clang`.
 BINDGEN_TARGET_x86	:= x86_64-linux-gnu
 BINDGEN_TARGET_arm64	:= aarch64-linux-gnu
 BINDGEN_TARGET_arm	:= arm-linux-gnueabi
 BINDGEN_TARGET_loongarch	:= loongarch64-linux-gnusf
+BINDGEN_TARGET_riscv	:= riscv64-linux-gnu
 BINDGEN_TARGET_um	:= $(BINDGEN_TARGET_$(SUBARCH))
 BINDGEN_TARGET		:= $(BINDGEN_TARGET_$(SRCARCH))
 
+ifeq ($(BINDGEN_TARGET),)
+$(error add '--target=' option to rust/Makefile)
+else
 # All warnings are inhibited since GCC builds are very experimental,
 # many GCC warnings are not supported by Clang, they may only appear in
 # some configurations, with new GCC versions, etc.
 bindgen_extra_c_flags = -w --target=$(BINDGEN_TARGET)
+endif
 
 # Auto variable zero-initialization requires an additional special option with
 # clang that is going to be removed sometime in the future (likely in
-- 
2.51.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script

[Miguel Ojeda]

On Wed, Sep 3, 2025 at 9:08 PM Asuna Yang <spriteovo@gmail.com> wrote:
>
> Decouple the code for getting the version of libclang used by Rust
> bindgen from rust_is_available.sh into a separate script so that we can
> define a symbol for the version in Kconfig that will be used for
> checking in subsequent patches.

Hmm... I am not sure it is a good idea to move that into another
script. Do we really need to intertwine these two scripts? The rename
isn't great either.

Cc'ing the rust-for-linux list too.

Thanks!

Cheers,
Miguel

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds

[Miguel Ojeda]

On Wed, Sep 3, 2025 at 9:08 PM Asuna Yang <spriteovo@gmail.com> wrote:
>
> Commit 33549fcf37ec ("RISC-V: disallow gcc + rust builds") disabled GCC
> + Rust builds for RISC-V due to differences in extension handling
> compared to LLVM.
>
> Add a Kconfig non-visible symbol to ensure that all important RISC-V
> specific flags that will be used by GCC can be correctly recognized by
> Rust bindgen's libclang, otherwise config HAVE_RUST will not be
> selected.

I think the commit message should try to explain each the changes here
(or to split them).

e.g. it doesn't mention the other config symbols added, nor the extra
flag skipped, nor the `error` call.

Cc'ing the rust-for-linux list.

Thanks!

Cheers,
Miguel

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: RISC-V: Re-enable GCC+Rust builds

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 1560 bytes --]

On Wed, Sep 03, 2025 at 08:59:29AM +0800, Asuna wrote:
> > That particular one might be a problem not because of -mstack-protector-guard itself, but rather three options get added at once:
> > 	$(eval KBUILD_CFLAGS += -mstack-protector-guard=tls		  \
> > 				-mstack-protector-guard-reg=tp		  \
> > 				-mstack-protector-guard-offset=$(shell	  \
> > 			awk '{if ($$2 == "TSK_STACK_CANARY") print $$3;}' \
> > 				$(objtree)/include/generated/asm-offsets.h))
> > and the other ones might be responsible for the error.
> 
> 
> I still don't understand the problem here. `bindgen_skip_c_flags` in
> `rust/Makefile` contains a pattern `-mstack-protector-guard%`, the % at the
> end enables it to match all those 3 options at the same time, and
> `filter-out` function removes them before passing to Rust bindgen's
> libclang. Am I missing something here?

If they don't ever appear with gcc + llvm builds, that's fine.

> > Similarly, something like -Wno-unterminated-string-initialization could cause a problem if gcc supports it but not libclang.
> 
> 
> Yes. However, this option is only about warnings, not architecture related
> and does not affect the generated results, so simply adding it into
> `bindgen_skip_c_flags` patterns should be enough, I think.
> 
> > I think you're mostly better off catching that sort of thing in Kconfig, where possible and just make incompatible mixes invalid. What's actually incompatible is likely going to depend heavily on what options are enabled.
> 
> Sounds better, I'll go down that path.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv