* [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script [not found] <20250830-cheesy-prone-ee5fae406c22@spud> @ 2025-09-03 19:07 ` Asuna Yang 2025-09-03 19:07 ` [PATCH 2/2] RISC-V: re-enable gcc + rust builds Asuna Yang 2025-09-03 23:24 ` [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script Miguel Ojeda 0 siblings, 2 replies; 12+ messages in thread From: Asuna Yang @ 2025-09-03 19:07 UTC (permalink / raw) To: Conor Dooley, Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook, Tejun Heo, Peter Zijlstra, Matthew Maurer, Jeff Xu, Jan Hendrik Farr, Shakeel Butt, Michal Koutný, Christian Brauner, Brian Gerst Cc: linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm, 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/2] RISC-V: re-enable gcc + rust builds 2025-09-03 19:07 ` [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script Asuna Yang @ 2025-09-03 19:07 ` Asuna Yang 2025-09-03 23:27 ` Miguel Ojeda 2025-09-04 12:27 ` Conor Dooley 2025-09-03 23:24 ` [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script Miguel Ojeda 1 sibling, 2 replies; 12+ messages in thread From: Asuna Yang @ 2025-09-03 19:07 UTC (permalink / raw) To: Conor Dooley, Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Tejun Heo, Kees Cook, Peter Zijlstra, Matthew Maurer, Jeff Xu, Shakeel Butt, Jan Hendrik Farr, Michal Koutný, Christian Brauner, Brian Gerst Cc: linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm, 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds 2025-09-03 19:07 ` [PATCH 2/2] RISC-V: re-enable gcc + rust builds Asuna Yang @ 2025-09-03 23:27 ` Miguel Ojeda 2025-09-04 23:17 ` Asuna 2025-09-04 12:27 ` Conor Dooley 1 sibling, 1 reply; 12+ messages in thread From: Miguel Ojeda @ 2025-09-03 23:27 UTC (permalink / raw) To: Asuna Yang Cc: Conor Dooley, Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Tejun Heo, Kees Cook, Peter Zijlstra, Matthew Maurer, Jeff Xu, Shakeel Butt, Jan Hendrik Farr, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm, rust-for-linux 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds 2025-09-03 23:27 ` Miguel Ojeda @ 2025-09-04 23:17 ` Asuna 0 siblings, 0 replies; 12+ messages in thread From: Asuna @ 2025-09-04 23:17 UTC (permalink / raw) To: Miguel Ojeda Cc: Conor Dooley, Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Tejun Heo, Kees Cook, Peter Zijlstra, Matthew Maurer, Jeff Xu, Shakeel Butt, Jan Hendrik Farr, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm, rust-for-linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds 2025-09-03 19:07 ` [PATCH 2/2] RISC-V: re-enable gcc + rust builds Asuna Yang 2025-09-03 23:27 ` Miguel Ojeda @ 2025-09-04 12:27 ` Conor Dooley 2025-09-04 22:56 ` Asuna 1 sibling, 1 reply; 12+ messages in thread From: Conor Dooley @ 2025-09-04 12:27 UTC (permalink / raw) To: Asuna Yang Cc: Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Tejun Heo, Kees Cook, Peter Zijlstra, Matthew Maurer, Jeff Xu, Shakeel Butt, Jan Hendrik Farr, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds 2025-09-04 12:27 ` Conor Dooley @ 2025-09-04 22:56 ` Asuna 2025-09-04 23:07 ` Asuna ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Asuna @ 2025-09-04 22:56 UTC (permalink / raw) To: Conor Dooley Cc: Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Tejun Heo, Kees Cook, Peter Zijlstra, Matthew Maurer, Jeff Xu, Shakeel Butt, Jan Hendrik Farr, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds 2025-09-04 22:56 ` Asuna @ 2025-09-04 23:07 ` Asuna 2025-09-05 15:25 ` Conor Dooley 2025-09-05 15:24 ` Conor Dooley 2025-09-05 15:28 ` Conor Dooley 2 siblings, 1 reply; 12+ messages in thread From: Asuna @ 2025-09-04 23:07 UTC (permalink / raw) To: Conor Dooley Cc: Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Tejun Heo, Kees Cook, Peter Zijlstra, Matthew Maurer, Jeff Xu, Shakeel Butt, Jan Hendrik Farr, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm, rust-for-linux CC rust-for-linux list, I missed it in copying from get_maintainer.pl, the thread is a bit of a mess now :( ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds 2025-09-04 23:07 ` Asuna @ 2025-09-05 15:25 ` Conor Dooley 0 siblings, 0 replies; 12+ messages in thread From: Conor Dooley @ 2025-09-05 15:25 UTC (permalink / raw) To: Asuna Cc: Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Tejun Heo, Kees Cook, Peter Zijlstra, Matthew Maurer, Jeff Xu, Shakeel Butt, Jan Hendrik Farr, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm, rust-for-linux [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds 2025-09-04 22:56 ` Asuna 2025-09-04 23:07 ` Asuna @ 2025-09-05 15:24 ` Conor Dooley 2025-09-05 15:28 ` Conor Dooley 2 siblings, 0 replies; 12+ messages in thread From: Conor Dooley @ 2025-09-05 15:24 UTC (permalink / raw) To: Asuna Cc: Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Tejun Heo, Kees Cook, Peter Zijlstra, Matthew Maurer, Jeff Xu, Shakeel Butt, Jan Hendrik Farr, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds 2025-09-04 22:56 ` Asuna 2025-09-04 23:07 ` Asuna 2025-09-05 15:24 ` Conor Dooley @ 2025-09-05 15:28 ` Conor Dooley 2 siblings, 0 replies; 12+ messages in thread From: Conor Dooley @ 2025-09-05 15:28 UTC (permalink / raw) To: Asuna Cc: Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Tejun Heo, Kees Cook, Peter Zijlstra, Matthew Maurer, Jeff Xu, Shakeel Butt, Jan Hendrik Farr, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script 2025-09-03 19:07 ` [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script Asuna Yang 2025-09-03 19:07 ` [PATCH 2/2] RISC-V: re-enable gcc + rust builds Asuna Yang @ 2025-09-03 23:24 ` Miguel Ojeda 2025-09-04 23:15 ` Asuna 1 sibling, 1 reply; 12+ messages in thread From: Miguel Ojeda @ 2025-09-03 23:24 UTC (permalink / raw) To: Asuna Yang Cc: Conor Dooley, Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook, Tejun Heo, Peter Zijlstra, Matthew Maurer, Jeff Xu, Jan Hendrik Farr, Shakeel Butt, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm, rust-for-linux 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script 2025-09-03 23:24 ` [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script Miguel Ojeda @ 2025-09-04 23:15 ` Asuna 0 siblings, 0 replies; 12+ messages in thread From: Asuna @ 2025-09-04 23:15 UTC (permalink / raw) To: Miguel Ojeda Cc: Conor Dooley, Jason Montleon, Han Gao, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook, Tejun Heo, Peter Zijlstra, Matthew Maurer, Jeff Xu, Jan Hendrik Farr, Shakeel Butt, Michal Koutný, Christian Brauner, Brian Gerst, linux-doc, linux-kernel, linux-riscv, linux-kbuild, llvm, rust-for-linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-09-05 15:28 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20250830-cheesy-prone-ee5fae406c22@spud>
2025-09-03 19:07 ` [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script Asuna Yang
2025-09-03 19:07 ` [PATCH 2/2] RISC-V: re-enable gcc + rust builds Asuna Yang
2025-09-03 23:27 ` Miguel Ojeda
2025-09-04 23:17 ` Asuna
2025-09-04 12:27 ` Conor Dooley
2025-09-04 22:56 ` Asuna
2025-09-04 23:07 ` Asuna
2025-09-05 15:25 ` Conor Dooley
2025-09-05 15:24 ` Conor Dooley
2025-09-05 15:28 ` Conor Dooley
2025-09-03 23:24 ` [PATCH 1/2] rust: get the version of libclang used by bindgen in a separate script Miguel Ojeda
2025-09-04 23:15 ` Asuna
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).