Re: [PATCH v4 4/4] RISC-V: fix gcc + rust builds

Re: [PATCH v4 4/4] RISC-V: fix gcc + rust builds

[Miguel Ojeda]

On Mon, Nov 24, 2025 at 1:23 AM 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.

This should mention what we are doing, i.e. re-enabling the GCC + Rust
support again.

Also, I would recommend avoiding to say "fix" in the title, unless it
is actually a fix, but perhaps the RISC-V maintainers consider it a
fix.

> Add `rust-bindgen-option` conditions for the availability of libclang to
> the RISC-V extension Kconfig symbols that depend on the `cc-option`
> function.

This is now in a different commit, right?

> Update the documentation, GCC + Rust builds for RISC-V are now
> supported.

"are now maintained" may be better to avoid confusing it with the
"Level of Support" in the table.

> Documentation/rust/arch-support.rst |  2 +-
> rust/Makefile                       |  3 ++-
> scripts/Makefile.rust               |  1 +

In any case, for the Rust bits, this seems OK (I didn't test it, though), so:

Acked-by: Miguel Ojeda <ojeda@kernel.org>

(By the way, I wouldn't mind if we started adding `MAINTAINERS`
entries on who is maintaining particular architectures for Rust,
especially if there is someone in particular involved with it etc.).

Thanks!

Cheers,
Miguel

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v4 4/4] RISC-V: fix gcc + rust builds

[Asuna Yang]

On 11/24/25 9:21 AM, Miguel Ojeda wrote:
>> Add `rust-bindgen-option` conditions for the availability of libclang to
>> the RISC-V extension Kconfig symbols that depend on the `cc-option`
>> function.
> This is now in a different commit, right?
Sorry, I may not have made it clear. I mean all these changes.

+	depends on !RUST || !64BIT || $(rust-bindgen-option,-- -mabi=lp64 -march=...)
+	depends on !RUST || !32BIT || $(rust-bindgen-option,-- -mabi=ilp32 -march=...)


> (By the way, I wouldn't mind if we started adding `MAINTAINERS`
> entries on who is maintaining particular architectures for Rust,
> especially if there is someone in particular involved with it etc.).
I had some contributions in rust-lang/rust repo for riscv64 (PR #131955, 
FWIW), and I'd like to be added as a Rust + RISC-V Linux maintainer if 
that's okay for you guys.

For the suggestions about commit messages, I will improve them in the 
next revision.

Thanks for your reviews!

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v4 4/4] RISC-V: fix gcc + rust builds

[Miguel Ojeda]

On Mon, Nov 24, 2025 at 3:05 AM Asuna Yang <spriteovo@gmail.com> wrote:
>
> Sorry, I may not have made it clear. I mean all these changes.

Ah, sorry, I missed the "conditions" word by reading too quickly and
misinterpreted it, my bad.

> I had some contributions in rust-lang/rust repo for riscv64 (PR #131955,
> FWIW), and I'd like to be added as a Rust + RISC-V Linux maintainer if
> that's okay for you guys.

I think having people explicitly listed like that would be great (e.g.
in an `... [RUST]` sub-entry to the ARCH one or similar, like we do in
other places), and it is a good way to contribute to Linux. I was
thinking about it for other architectures too. But let's see what
RISC-V maintainers think about it.

Thanks!

Cheers,
Miguel

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v4 2/4] rust: generate a fatal error if BINDGEN_TARGET is undefined

[Miguel Ojeda]

On Mon, Nov 24, 2025 at 1:23 AM Asuna Yang <spriteovo@gmail.com> wrote:
>
> Generate a friendly fatal error if the target triplet is undefined for
> bindgen, rather than having the compiler generate obscure error messages
> during the build stage.

I normally suggest putting in the log the errors in case someone
searches for them and for future reference etc.

Acked-by: Miguel Ojeda <ojeda@kernel.org>

Cheers,
Miguel

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v4 1/4] rust: export BINDGEN_TARGET from a separate Makefile

[Miguel Ojeda]

On Mon, Nov 24, 2025 at 1:23 AM Asuna Yang <spriteovo@gmail.com> wrote:
>
> A subsequent commit will add a new function `rust-bindgen-option` to
> `scripts/Kconfig.include`. The bindgen backend requires the `--target`
> option for cross compiling, but variable `BINDGEN_TARGET` in
> `rust/Makefile` cannot be exported to `scripts/Kconfig.include`.

Please end with another paragraph saying what the commit does, e.g.
"Thus move the variable to a new `Makefile` that can then be imported
from the main `Makefile`" or similar.

Also, I am not sure if this should be called `Makefile.bindgen`, but I
guess it is fine as it is -- with the current name, the new file
should be covered by the `F: scripts/*rust*` rule in `MAINTAINERS`
already, so this looks OK, but please double-check it is the case.

Finally, is it possible to put this under `need-compiler` like
`Makefile.compiler`? I don't think we need to evaluate those options
for things like `make help`, but perhaps I am missing something.
Please see commit 805b2e1d427a ("kbuild: include Makefile.compiler
only when compiler is needed").

Thanks!

Cheers,
Miguel

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v4 3/4] rust: add a Kconfig function to test for support of bindgen options

[Miguel Ojeda]

On Mon, Nov 24, 2025 at 1:23 AM Asuna Yang <spriteovo@gmail.com> wrote:
>
> Use the `BINDGEN_EXTRA_CLANG_ARGS` environment variable to pass the
> `--target` option for cross compiling, so that the function can be used
> to test both bindgen options and bindgen backend options.

It seems this explains part of how it works, but not what the commit
adds and why, i.e. could we start with "Add `rustc-bindgen-option`..."
etc.?

By the way, shouldn't this just be called `bindgen-option`? Up to the
Kbuild team.

More importantly, should we just have a separate function for backend
flags? That would be easier and would avoid having to use the
environment variable, if I understand the commit message here
correctly. And, anyway, it is actually the only function we need so
far.

> +# Return y if the Rust bindgen supports <flag>, n otherwise

Maybe just "y if bindgen supports"?

Thanks!

Cheers,
Miguel

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v4 3/4] rust: add a Kconfig function to test for support of bindgen options

[Asuna Yang]

On 11/24/25 9:48 AM, Miguel Ojeda wrote:
> More importantly, should we just have a separate function for backend
> flags? That would be easier and would avoid having to use the
> environment variable, if I understand the commit message here
> correctly. And, anyway, it is actually the only function we need so
> far.

You are right, separated might be better.

Another reason is, in `scripts/Makefile.compiler`, there is a set of 
functions with the same name provided for use by Makefile. Since we 
currently do not need to check for bindgen options in Makefile, I didn't 
add function for bindgen there. If we add it in the future, the 
`bindgen-option` function in `Kconfig.include` will correspond to the 
`bindgen-option-yn` function in `Makefile.compiler`, and 
`bindgen-option` function in `Makefile.compiler` will return the 
selected option instead of yn.

If we don't separate them now, for consistency, in `Makefile.compiler`, 
`$(call bindgen-option,-- --some-flag-a,-- --some-flag-b)` will return 
an option prefixed with --, which makes it difficult to use.

I will separate them into two functions in the next revision, 
`bindgen-option` and `bindgen-backend-option` (or `bindgen-cc-option`? 
Which one do you prefer?).

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v4 3/4] rust: add a Kconfig function to test for support of bindgen options

[Miguel Ojeda]

On Mon, Nov 24, 2025 at 3:42 AM Asuna Yang <spriteovo@gmail.com> wrote:
>
> I will separate them into two functions in the next revision,
> `bindgen-option` and `bindgen-backend-option` (or `bindgen-cc-option`?
> Which one do you prefer?).

If we don't need `bindgen-option` (the normal one I mean) so far,
perhaps we should skip it. On the other hand, `rustc-option-yn` is
there and is not used either (it was added for consistency). Up to the
Kbuild team, I guess.

As for the name, no strong preference. `bindgen-backend-option` sounds
good, but `bindgen-cc-option` is more consistent with `cc-option` and
probably easier to understand for people new to `bindgen`, and anyway
the flags we pass there wouldn't make sense if the backend is not a C
compiler.

Thanks!

Cheers,
Miguel

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v4 3/4] rust: add a Kconfig function to test for support of bindgen options

[Nathan Chancellor]

On Mon, Nov 24, 2025 at 04:08:36AM +0100, Miguel Ojeda wrote:
> On Mon, Nov 24, 2025 at 3:42 AM Asuna Yang <spriteovo@gmail.com> wrote:
> >
> > I will separate them into two functions in the next revision,
> > `bindgen-option` and `bindgen-backend-option` (or `bindgen-cc-option`?
> > Which one do you prefer?).
> 
> If we don't need `bindgen-option` (the normal one I mean) so far,
> perhaps we should skip it. On the other hand, `rustc-option-yn` is
> there and is not used either (it was added for consistency). Up to the
> Kbuild team, I guess.

I do not have a strong preference one way or the other. These macros
tend to be low maintenance and do not take up much space regardless so
preemptively adding it so that it is ready for use in the future is no
big deal in my opinion.

> As for the name, no strong preference. `bindgen-backend-option` sounds
> good, but `bindgen-cc-option` is more consistent with `cc-option` and
> probably easier to understand for people new to `bindgen`, and anyway
> the flags we pass there wouldn't make sense if the backend is not a C
> compiler.

Yeah, I think either one sort of requires knowledge of bindgen to know
the difference between a flag to bindgen and a flag to the C compiler
behind bindgen so no strong preference from my side (Nicolas may feel
differently).

Cheers,
Nathan

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv