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

[Conor Dooley <conor@kernel.org>]

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

On Tue, Sep 09, 2025 at 06:53:11PM +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 symbol to indicate the version of libclang used by Rust
> bindgen and add conditions for the availability of libclang to the
> RISC-V extension Kconfig symbols that depend on the cc-option function.
> 
> For Zicsr/Zifencei special handling, since LLVM/Clang always enables
> these two extensions, either don't pass them to -march, or pass them
> explicitly and Rust bindgen libclang must recognize them.
> 
> Clang does not support -mno-riscv-attribute flag, filter it out to
> resolve error: unknown argument: '-mno-riscv-attribute'.
> 
> Define BINDGEN_TARGET_riscv to pass the target triplet to Rust bindgen
> libclang for RISC-V to resolve error: unsupported argument 'medany' to
> option '-mcmodel=' for target 'unknown'. Improve to output a clearer
> error message if the target triplet is undefined for Rust bindgen
> libclang.
> 
> Update the documentation, GCC + Rust builds are now supported.
> 
> ---

FWIW, this --- breaks git, and anything after this line (including your
signoff) is lost when the patch is applied.

> Discussion:
> https://lore.kernel.org/linux-riscv/68496eed-b5a4-4739-8d84-dcc428a08e20@gmail.com/
> Patch v1:
> https://lore.kernel.org/linux-riscv/20250903190806.2604757-1-SpriteOvO@gmail.com/
> 
> GCC + Rust builds for RISC-V are disabled about a year ago due to differences in
> extension handling compared to LLVM, as discussed in
> https://lore.kernel.org/all/20240917000848.720765-1-jmontleo@redhat.com/
> 
> This patch re-enables GCC + Rust builds. Compared to v1, v2 reverts the
> separation of get-rust-bindgen-libclang script and improves Kconfig conditions
> based on Conor's review.
> 
> The separation of get-rust-bindgen-libclang script is reverted based on the
> concerns raised by Miguel. However, it's worth noting that we now have 3
> different places rust/Makefile scripts/{Kconfig.include,rust_is_avilable.sh}
> where manually calling bindgen rust_is_available_bindgen_libclang.h + sed to get
> the version of libclang, and in particular, for our newly added Kconfig symbol,
> we now use awk to canonicalize the version to an integer. I would still like to
> do the script separation later for better maintainability and readability if
> possible, which can be discussed further later when Miguel has time.
> 
> Signed-off-by: Asuna Yang <SpriteOvO@gmail.com>

> diff --git a/init/Kconfig b/init/Kconfig
> index e3eb63eadc8757a10b091c74bbee8008278c0521..0859d308a48591df769c7dbaef6f035324892bd3 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.

The riscv patchwork CI stuff is really unhappy with this change:
init/Kconfig:87: syntax error
init/Kconfig:87: invalid statement
init/Kconfig:88: invalid statement
init/Kconfig:89:warning: ignoring unsupported character '`'
init/Kconfig:89:warning: ignoring unsupported character '`'
init/Kconfig:89:warning: ignoring unsupported character '.'
init/Kconfig:89: unknown statement "This"

Is this bogus, or can rustc-bindgen-libclang-version return nothing
under some conditions where rust is not available?
Should this have 2 default lines like some other options in the file?

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