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.

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

[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: 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 --]