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.

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

[Conor Dooley]

[-- Attachment #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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Conor Dooley]

[-- Attachment #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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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.

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

[Conor Dooley]

[-- Attachment #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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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.

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.

[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

[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

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

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

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

[Conor Dooley]

[-- Attachment #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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Conor Dooley]

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

On Wed, Sep 03, 2025 at 09:07:57PM +0200, Asuna Yang 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.
> 
> Signed-off-by: Asuna Yang <SpriteOvO@gmail.com>

Thanks for working on this. One thing - please don't send new versions
of patchsets in response to earlier versions or other threads. It
doesn't do you any favours with mailbox visibility.

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

Other than Zicsr/Zifencei that may need explicit handling in a dedicated
option, the approach here seems kinda backwards.
Individually these symbols don't actually mean what they say they do,
which is confusing: "recognises" here is true even when it may not be
true at all because TOOLCHAIN_HAS_FOO is not set. Why can these options
not be removed, and instead the TOOLCHAIN_HAS_FOO options grow a
"depends on !RUST || <condition>"?

> +	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_ZBCawl
>  	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)

What does the libclang >= 17 requirement actually do here? Is that the
version where llvm starts to require that Zicsr/Zifencei is set in order
to use them? I think a comment to that effect is required if so. This
doesn't actually need to be blocking either, should just be able to
filter it out of march when passing to bindgen, no?

What about the case where TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI is not
set at all? Currently your patch is going to block rust in that case,
when actually nothing needs to be done at all - no part of the toolchain
requires understanding Zicsr/Zifencei as standalone extensions in this
case.

The TOOLCHAIN_NEEDS_OLD_ISA_SPEC handling I don't remember 100% how it
works, but if bindgen requires them to be set to use the extension
this will return true but do nothing to add the extensions to march?
That seems wrong to me.
I'd be fairly amenable to disabling rust though when used in combination
with gcc < 11.3 and gas >=2.36 since it's such a niche condition, rather
doing work to support it. That'd be effectively an inversion of your
first condition.

You could probably do something like blocking rust if
TOOLCHAIN_NEEDS_OLD_ISA_SPEC and where TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
is set in combination with an older libclang - so like:

	select HAVE_RUST if FOO && !ZICSR_ZIFENCEI_MISMATCH

config ZICSR_ZIFENCEI_MISMATCH
	def_bool y
	depends on TOOLCHAIN_NEEDS_OLD_ISA_SPEC || (TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI && RUST_BINDGEN_LIBCLANG_VERSION < 170000)

or alternatively, make a Kconfig option for the later half of that
condition along the lines of:

config BINDGEN_FILTER_OUT_ZICSR_ZIFENCEI
	def_bool y
	depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI && RUST_BINDGEN_LIBCLANG_VERSION < 170000

and use it to filter out _zicsr_zifencei and make the select

	select HAVE_RUST if FOO && !TOOLCHAIN_NEEDS_OLD_ISA_SPEC


FWIW the reason that these odd mixes have dedicated work done for them
in Kconfig is that the ?Linaro? CI infrastructure was running clang +
binutils builds with a version of LLVM that predated us having full
LLVM=1 support and it was done to stop that CI infrastructure falling
over constantly.

Cheers,
Conor.

> +
>  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
> 

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

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

[Asuna]

> One thing - please don't send new versions
> of patchsets in response to earlier versions or other threads. It
> doesn't do you any favours with mailbox visibility.

I apologize for this, I'm pretty much new to mailing lists, so I had 
followed the step "Explicit In-Reply-To headers" [1] in doc. For future 
patches I'll send them alone instead of replying to existing threads.

[1]: 
https://www.kernel.org/doc/html/v6.9/process/submitting-patches.html#explicit-in-reply-to-headers

> Other than Zicsr/Zifencei that may need explicit handling in a dedicated
> option, the approach here seems kinda backwards.
> Individually these symbols don't actually mean what they say they do,
> which is confusing: "recognises" here is true even when it may not be
> true at all because TOOLCHAIN_HAS_FOO is not set. Why can these options
> not be removed, and instead the TOOLCHAIN_HAS_FOO options grow a
> "depends on !RUST || <condition>"?

Yes, it's kinda "backwards", which is intentional, based on the 
following considerations:

1) As mentioned in rust/Makefile, filtering flags for libclang is a 
hack, because currently bindgen only has libclang as backend, and 
ideally bindgen should support GCC so that the passed CC flags are 
supposed to be fully compatible. On the RISC-V side, I tend to think 
that version checking for extensions for libclang is also a hack, which 
could have been accomplished with just the cc-option function, ideally.

2) Rust bindgen only "generates" FFI stuff, it is not involved in the 
final assembly stage. In other words, it doesn't matter so much what 
RISC-V extensions to turn on for bindgen (although it does have a little 
impact, like some macro switches), it's more matter to CC.

Therefore, I chose not to modify the original extension config 
conditions so that if libclang doesn't support the CC flag for an 
extension, then the Rust build is not supported, rather than treating 
the extension as not supported.

Nonetheless, it occurred to me as I was writing this reply that if GCC 
implements a new extension in the future that LLVM/Clang doesn't yet 
have, this could once again lead to a break in GCC+Rust build support if 
the kernel decides to use the new extension. So it's a trade-off, you 
guys decide, I'm fine with both.

Regarding the name, initially I named it "compatible", and ended up 
changed it to "recognize" before sending the patch. If we continue on 
this path, I'm not sure what name is appropriate to use here, do you 
guys have any ideas?

> What does the libclang >= 17 requirement actually do here? Is that the
> version where llvm starts to require that Zicsr/Zifencei is set in order
> to use them? I think a comment to that effect is required if so. This
> doesn't actually need to be blocking either, should just be able to
> filter it out of march when passing to bindgen, no?

libclang >= 17 starts recognizing Zicsr/Zifencei in -march, passing them 
to -march doesn't generate an error, and passing them or not doesn't 
have any real difference. (still follows ISA before version 20190608 -- 
Zicsr/Zifencei are included in base ISA). I should have written a 
comment there to avoid confusion.

Reference commit in LLVM/Clang 22e199e6af ("[RISCV] Accept zicsr and 
zifencei command line options")
https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16

> What about the case where TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI is not
> set at all? Currently your patch is going to block rust in that case,
> when actually nothing needs to be done at all - no part of the toolchain
> requires understanding Zicsr/Zifencei as standalone extensions in this
> case.

This is a bug, I missed this case. So it should be corrected to:

    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


> The TOOLCHAIN_NEEDS_OLD_ISA_SPEC handling I don't remember 100% how it
> works, but if bindgen requires them to be set to use the extension
> this will return true but do nothing to add the extensions to march?
> That seems wrong to me.
> I'd be fairly amenable to disabling rust though when used in combination
> with gcc < 11.3 and gas >=2.36 since it's such a niche condition, rather
> doing work to support it. That'd be effectively an inversion of your
> first condition.

The current latest version of LLVM/Clang still does not require explicit 
Zicsr/Zifence to enable these two extensions, Clang just accepts them in 
-march and then silently ignores them.

Checking the usage of CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC:

    ifdef CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC
    KBUILD_CFLAGS += -Wa,-misa-spec=2.2
    KBUILD_AFLAGS += -Wa,-misa-spec=2.2
    else
    riscv-march-$(CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI) :=
    $(riscv-march-y)_zicsr_zifencei
    endif

It just uses -Wa to force an older ISA version to GAS. So the 
RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZICSR_ZIFENCEI I corrected above should 
be fine now I guess? Or would you still prefer your idea of blocking 
Rust if TOOLCHAIN_NEEDS_OLD_ISA_SPEC is true?

(To be clear, the breaking changes regarding Zicsr/Zifence are since ISA 
version 20190608, and versions 2.0, 2.1, 2.2 are older than 20190608)

The only thing I'm confused about is that according to the comment of 
TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI, GCC-12.1.0 bumped the default 
ISA to 20191213, but why doesn't the depends-on have condition || 
(CC_IS_GCC && GCC_VERSION >= 120100)?

Thanks for your detailed review.

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

[Asuna]

CC rust-for-linux list, I missed it in copying from get_maintainer.pl, 
the thread is a bit of a mess now :(

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

[Asuna]

On 9/4/25 7:24 AM, Miguel Ojeda wrote:
> 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.
>
Because of adding a new Kconfig symbol for the Rust bindgen libclang 
version, then we have three places manually calling bindgen for 
rust_is_available_bindgen_libclang.h to get the version. I'd like to 
merge them into one script so that it's easy to maintain in the future. 
But if you prefer not to, I'd also be willing to revert it.

For this approach and naming, I referred to script/cc-version.sh 
rustc-version.sh and rustc-llvm-version.sh.

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

[Asuna]

On 9/4/25 7:27 AM, Miguel Ojeda wrote:
> 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.
Yes, the commit message is worth being more detailed, I'll improve it in 
the v2 patch.

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

[Conor Dooley]

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

Yo,

On Fri, Sep 05, 2025 at 06:56:35AM +0800, Asuna wrote:
> > One thing - please don't send new versions
> > of patchsets in response to earlier versions or other threads. It
> > doesn't do you any favours with mailbox visibility.
> 
> I apologize for this, I'm pretty much new to mailing lists, so I had
> followed the step "Explicit In-Reply-To headers" [1] in doc. For future
> patches I'll send them alone instead of replying to existing threads.
> 
> [1]: https://www.kernel.org/doc/html/v6.9/process/submitting-patches.html#explicit-in-reply-to-headers
> 
> > Other than Zicsr/Zifencei that may need explicit handling in a dedicated
> > option, the approach here seems kinda backwards.
> > Individually these symbols don't actually mean what they say they do,
> > which is confusing: "recognises" here is true even when it may not be
> > true at all because TOOLCHAIN_HAS_FOO is not set. Why can these options
> > not be removed, and instead the TOOLCHAIN_HAS_FOO options grow a
> > "depends on !RUST || <condition>"?
> 
> Yes, it's kinda "backwards", which is intentional, based on the following
> considerations:
> 
> 1) As mentioned in rust/Makefile, filtering flags for libclang is a hack,
> because currently bindgen only has libclang as backend, and ideally bindgen
> should support GCC so that the passed CC flags are supposed to be fully
> compatible. On the RISC-V side, I tend to think that version checking for
> extensions for libclang is also a hack, which could have been accomplished
> with just the cc-option function, ideally.
> 
> 2) Rust bindgen only "generates" FFI stuff, it is not involved in the final
> assembly stage. In other words, it doesn't matter so much what RISC-V
> extensions to turn on for bindgen (although it does have a little impact,
> like some macro switches), it's more matter to CC.

> Therefore, I chose not to modify the original extension config conditions so
> that if libclang doesn't support the CC flag for an extension, then the Rust
> build is not supported, rather than treating the extension as not supported.

I don't agree with this take, I don't think that any extension should
"blindly" take priority over rust like this. Got two or three main gripes
with how it is being done here.
Firstly, you're lumping every extension into one option even though many
of them will not be even implemented on the target. There's no need to
disable rust if the user has no intention of even making use of the
extension that would block its use. That runs into the second point, in
that you're using TOOLCHAIN_HAS_FOO here, which is only an indicator of
whether the toolchain supports the extension not whether the kernel is
even going to use it. The third problem I have is that the symbol you're
interacting with is not user selectable, and therefore doesn't allow the
user to decide whether or not a particular extension or rust support
with the toolchain they have is the higher priority. If the check moves
to the individual TOOLCHAIN_HAS_FOO options, they could be a

	depends on !RUST || <condition>

which would allow the user to make a decision about which has a greater
priority while also handling the extensions individually.

> Nonetheless, it occurred to me as I was writing this reply that if GCC
> implements a new extension in the future that LLVM/Clang doesn't yet have,
> this could once again lead to a break in GCC+Rust build support if the
> kernel decides to use the new extension. So it's a trade-off, you guys
> decide, I'm fine with both.
> 
> Regarding the name, initially I named it "compatible", and ended up changed
> it to "recognize" before sending the patch. If we continue on this path, I'm
> not sure what name is appropriate to use here, do you guys have any ideas?
> 
> > What does the libclang >= 17 requirement actually do here? Is that the
> > version where llvm starts to require that Zicsr/Zifencei is set in order
> > to use them? I think a comment to that effect is required if so. This
> > doesn't actually need to be blocking either, should just be able to
> > filter it out of march when passing to bindgen, no?
> 
> libclang >= 17 starts recognizing Zicsr/Zifencei in -march, passing them to
> -march doesn't generate an error, and passing them or not doesn't have any
> real difference. (still follows ISA before version 20190608 --
> Zicsr/Zifencei are included in base ISA). I should have written a comment
> there to avoid confusion.
> 
> Reference commit in LLVM/Clang 22e199e6af ("[RISCV] Accept zicsr and
> zifencei command line options")
> https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
> 
> > What about the case where TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI is not
> > set at all? Currently your patch is going to block rust in that case,
> > when actually nothing needs to be done at all - no part of the toolchain
> > requires understanding Zicsr/Zifencei as standalone extensions in this
> > case.
> 
> This is a bug, I missed this case. So it should be corrected to:
> 
>    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
> 
> 
> > The TOOLCHAIN_NEEDS_OLD_ISA_SPEC handling I don't remember 100% how it
> > works, but if bindgen requires them to be set to use the extension
> > this will return true but do nothing to add the extensions to march?
> > That seems wrong to me.
> > I'd be fairly amenable to disabling rust though when used in combination
> > with gcc < 11.3 and gas >=2.36 since it's such a niche condition, rather
> > doing work to support it. That'd be effectively an inversion of your
> > first condition.
> 
> The current latest version of LLVM/Clang still does not require explicit
> Zicsr/Zifence to enable these two extensions, Clang just accepts them in
> -march and then silently ignores them.
> 
> Checking the usage of CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC:
> 
>    ifdef CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC
>    KBUILD_CFLAGS += -Wa,-misa-spec=2.2
>    KBUILD_AFLAGS += -Wa,-misa-spec=2.2
>    else
>    riscv-march-$(CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI) :=
>    $(riscv-march-y)_zicsr_zifencei
>    endif
> 
> It just uses -Wa to force an older ISA version to GAS. So the
> RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZICSR_ZIFENCEI I corrected above should be
> fine now I guess? Or would you still prefer your idea of blocking Rust if
> TOOLCHAIN_NEEDS_OLD_ISA_SPEC is true?

Nah, if the explicit setting isn't required then it should be fine to
not block on it being used. To be honest, I'm not concerned about
Zicsr/Zifencei being communicated across to bindgen as much as I would
be about other extensions, my motivation here is regarding build
breakages - in particular when things like TOOLCHAIN_NEEDS_OLD_ISA_SPEC
is set, since it's a very niche configuration that if someone told me
they were using I would tell them to stop. As I said, the original
reason for this existing was to support w/e old version of debian linaro
were using that could not do LLVM=1 builds and I think the person who
added to this handle gcc with older binutils was trying to do a gradual
move from an old toolchain in steps to a modern one, so neither were
instances of someone actually wanting to use such a strange mix.

> (To be clear, the breaking changes regarding Zicsr/Zifence are since ISA
> version 20190608, and versions 2.0, 2.1, 2.2 are older than 20190608)
> 
> The only thing I'm confused about is that according to the comment of
> TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI, GCC-12.1.0 bumped the default ISA
> to 20191213, but why doesn't the depends-on have condition || (CC_IS_GCC &&
> GCC_VERSION >= 120100)?

It's probably something along the lines of there being no _C_ code that
produces the Zicsr and Zifencei instructions, and therefore no build
errors produced if they're missing. That's part of why I said my
motivation in this particular case is build breakage, more than anything
else.

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

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

[Conor Dooley]

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

On Fri, Sep 05, 2025 at 07:07:20AM +0800, Asuna wrote:
> CC rust-for-linux list, I missed it in copying from get_maintainer.pl, the
> thread is a bit of a mess now :(

If you're doing that, keep the whole message in the mail. Think I just
perpetuated the problem by replying to the mail a body rather than the
one with the amended CC list.

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

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

[Conor Dooley]

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

On Fri, Sep 05, 2025 at 06:56:35AM +0800, Asuna wrote:
> > One thing - please don't send new versions
> > of patchsets in response to earlier versions or other threads. It
> > doesn't do you any favours with mailbox visibility.
> 
> I apologize for this, I'm pretty much new to mailing lists, so I had
> followed the step "Explicit In-Reply-To headers" [1] in doc. For future
> patches I'll send them alone instead of replying to existing threads.
> 
> [1]: https://www.kernel.org/doc/html/v6.9/process/submitting-patches.html#explicit-in-reply-to-headers

Ye I think this is mostly just misleading. You're better off providing a
lore link in the body of the mail than replying to some old thread. I
find that explicit in-reply-to stuff only really helpful to send a
single patch as part of a conversation where it's effectively an RFC.

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