linux-kernel - Re: [PATCH] RISC-V: Fix building rust when using GCC toolchain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <31885EDD-EF6D-4EF1-94CA-276BA7A340B7@kernel.org>
Date: Tue, 17 Sep 2024 17:26:40 +0200
From: Conor Dooley <conor@...nel.org>
To: Gary Guo <gary@...yguo.net>
CC: Jason Montleon <jmontleo@...hat.com>, ojeda@...nel.org, alex.gaynor@...il.com,
 boqun.feng@...il.com, bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
 a.hindborg@...nel.org, aliceryhl@...gle.com, paul.walmsley@...ive.com,
 palmer@...belt.com, aou@...s.berkeley.edu, nathan@...nel.org,
 ndesaulniers@...gle.com, morbo@...gle.com, justinstitt@...gle.com,
 rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-riscv@...ts.infradead.org, llvm@...ts.linux.dev,
 stable@...r.kernel.org
Subject: Re: [PATCH] RISC-V: Fix building rust when using GCC toolchain



On 17 September 2024 15:29:50 GMT+02:00, Gary Guo <gary@...yguo.net> wrote:
>On Tue, 17 Sep 2024 10:35:12 +0100
>Conor Dooley <conor@...nel.org> wrote:
>
>> On 17 September 2024 01:08:48 IST, Jason Montleon <jmontleo@...hat.com> wrote:
>> >Clang does not support '-mno-riscv-attribute' resulting in the error
>> >error: unknown argument: '-mno-riscv-attribute'  
>> 
>> This appears to conflict with your subject, which cities gcc, but I suspect that's due to poor wording of the body of the commit message than a mistake in the subject.
>> I'd rather disable rust on riscv when building with gcc, I've never been satisfied with the interaction between gcc and rustc's libclang w.r.t. extensions.
>> 
>> Cheers,
>> Conor.
>
>Hi Conor,
>
>What happens is that when building against GCC, Kbuild gathers flag
>assuming CC is GCC, but bindgen uses clang instead. In this case, the
>CC is GCC and all C code is built by GCC. We have a filtering mechanism
>to only give bindgen (libclang) flags that it can understand.

Yes, but unfortunately I already knew how it worked. It's not flags I am worried about, it is extensions.
Even using a libclang that doesn't match clang could be a problem, but we can at least declare that unsupported.
Not digging it out on an airport bus, but we discussed the lack of GCC support on the original patch adding riscv, and decided against it.

>
>While I do think this is a bit fragile, this is what I think all
>distros that enable Rust use. They still prefer to build C code with
>GCC. So I hope we can still keep that option around.
>
>Best,
>Gary
>
>
>> 
>> >
>> >Not setting BINDGEN_TARGET_riscv results in the in the error
>> >error: unsupported argument 'medany' to option '-mcmodel=' for target \
>> >'unknown'
>> >error: unknown target triple 'unknown'
>> >
>> >Signed-off-by: Jason Montleon <jmontleo@...hat.com>
>> >Cc: stable@...r.kernel.org
>> >---
>> > rust/Makefile | 3 ++-
>> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> >diff --git a/rust/Makefile b/rust/Makefile
>> >index f168d2c98a15..73eceaaae61e 100644
>> >--- a/rust/Makefile
>> >+++ b/rust/Makefile
>> >@@ -228,11 +228,12 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \
>> > 	-fzero-call-used-regs=% -fno-stack-clash-protection \
>> > 	-fno-inline-functions-called-once -fsanitize=bounds-strict \
>> > 	-fstrict-flex-arrays=% -fmin-function-alignment=% \
>> >-	--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_riscv	:= riscv64-linux-gnu
>> > BINDGEN_TARGET		:= $(BINDGEN_TARGET_$(SRCARCH))
>> > 
>> > # All warnings are inhibited since GCC builds are very experimental,
>> >
>> >base-commit: ad060dbbcfcfcba624ef1a75e1d71365a98b86d8  
>