Enable experimental rust support for ppc64le and ppc32be. The patch for
ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been
merged over it. ppc32 needs some toolchain fixes mentioned in the patch
`rust: Add PowerPC support` and the discussion for that is done here[1].
This has been tested on powernv9 hardware and power10 pseries qemu. I
I request Link to test the ppc32 part as i don't have a hardware to test
it out.
[1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr
[2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com
Changelog:
V5 -> V6:
- Added a missing Tested by from Venkat which got missed since V3
- Support is marked as Maintained instead of experimental
V5: https://lore.kernel.org/all/20260210053756.2088302-1-mkchauras@gmail.com
V4 -> V5:
- Removed a nested ifdef from PPC64 for Little endian toolchain
V4: https://lore.kernel.org/all/20260209105456.1551677-1-mkchauras@gmail.com
V3 -> V4:
- Co-developed-by header added in patch 1
V3: https://lore.kernel.org/all/20260205180429.3280657-1-mkchauras@gmail.com
V2 -> V3:
- Splited HAVE_RUST in 2 lines
- BINDGEN_TARGET_powerpc initialized before assigning the same to
BINDGEN_TARGET
V2: https://lore.kernel.org/all/20260204210125.613350-1-mkchauras@gmail.com
V1 -> V2:
- jump label fix for rust has been moved to a separate patch
- PPC32 support has been taken
- rust support has been marked experimental
- target.json dependency has been removed
- HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64
Link Mauve (1):
rust: Add PowerPC support
Mukesh Kumar Chaurasiya (IBM) (2):
powerpc/jump_label: adjust inline asm to be consistent
powerpc: Enable Rust for ppc64le
Documentation/rust/arch-support.rst | 1 +
arch/powerpc/Kconfig | 2 ++
arch/powerpc/Makefile | 7 +++++++
arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
rust/Makefile | 10 +++++++++-
5 files changed, 32 insertions(+), 11 deletions(-)
--
2.53.0
Added support for a new macro ARCH_STATIC_BRANCH_ASM in powerpc
to avoid duplication of inline asm between C and Rust. This is
inline with commit aecaf181651c '("jump_label: adjust inline asm to be consistent")'
Co-developed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <redacted>
---
arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
From: Link Mauve <redacted>
For now only Big Endian 32-bit PowerPC is supported, as that is the only
hardware I have. This has been tested on the Nintendo Wii so far, but I
plan on also using it on the GameCube, Wii U and Apple G4.
These changes aren’t the only ones required to get the kernel to compile
and link on PowerPC, libcore will also have to be changed to not use
integer division to format u64, u128 and core::time::Duration, otherwise
__udivdi3() and __umoddi3() will have to be added. I have tested this
change by replacing the three implementations with unimplemented!() and
it linked just fine.
Signed-off-by: Link Mauve <redacted>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <redacted>
---
Documentation/rust/arch-support.rst | 1 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 2 ++
rust/Makefile | 4 +++-
4 files changed, 7 insertions(+), 1 deletion(-)
From: Alice Ryhl <aliceryhl@google.com> Date: 2026-02-22 18:09:52
On Tue, Feb 10, 2026 at 10:00 AM Mukesh Kumar Chaurasiya (IBM)
[off-list ref] wrote:
From: Link Mauve <redacted>
For now only Big Endian 32-bit PowerPC is supported, as that is the only
hardware I have. This has been tested on the Nintendo Wii so far, but I
plan on also using it on the GameCube, Wii U and Apple G4.
These changes aren’t the only ones required to get the kernel to compile
and link on PowerPC, libcore will also have to be changed to not use
integer division to format u64, u128 and core::time::Duration, otherwise
__udivdi3() and __umoddi3() will have to be added. I have tested this
change by replacing the three implementations with unimplemented!() and
it linked just fine.
Signed-off-by: Link Mauve <redacted>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <redacted>
From: Miguel Ojeda <hidden> Date: 2026-02-22 19:11:30
On Sun, Feb 22, 2026 at 8:07 PM Link Mauve [off-list ref] wrote:
Should we come back to describing the target like I did in my first
patch[1] in scripts/generate_rust_target.rs, or should I bring that to
Rust to create a powerpc-unknown-unknown-softfloat target upstream? Or
is there a better third solution I’m not thinking of?
We are trying to stop using the custom target specs, so we should ask
upstream to give you a built-in target you can use (or equivalently, a
flag to do what you need, but I think the idea is to not have such a
flag).
i.e. even if you used the custom target JSON, we would still need to
ask, since the goal is to remove that script entirely.
Thanks!
Cheers,
Miguel
From: Link Mauve <hidden> Date: 2026-02-22 19:13:34
On Sun, Feb 22, 2026 at 07:09:38PM +0100, Alice Ryhl wrote:
On Tue, Feb 10, 2026 at 10:00 AM Mukesh Kumar Chaurasiya (IBM)
[off-list ref] wrote:
quoted
From: Link Mauve <redacted>
For now only Big Endian 32-bit PowerPC is supported, as that is the only
hardware I have. This has been tested on the Nintendo Wii so far, but I
plan on also using it on the GameCube, Wii U and Apple G4.
These changes aren’t the only ones required to get the kernel to compile
and link on PowerPC, libcore will also have to be changed to not use
integer division to format u64, u128 and core::time::Duration, otherwise
__udivdi3() and __umoddi3() will have to be added. I have tested this
change by replacing the three implementations with unimplemented!() and
it linked just fine.
Signed-off-by: Link Mauve <redacted>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <redacted>
Should we come back to describing the target like I did in my first
patch[1] in scripts/generate_rust_target.rs, or should I bring that to
Rust to create a powerpc-unknown-unknown-softfloat target upstream? Or
is there a better third solution I’m not thinking of?
On Mon, 23 Feb 2026 at 00:41, Miguel Ojeda [off-list ref]
wrote:
On Sun, Feb 22, 2026 at 8:07 PM Link Mauve [off-list ref] wrote:
quoted
Should we come back to describing the target like I did in my first
patch[1] in scripts/generate_rust_target.rs, or should I bring that to
Rust to create a powerpc-unknown-unknown-softfloat target upstream? Or
is there a better third solution I’m not thinking of?
We are trying to stop using the custom target specs, so we should ask
upstream to give you a built-in target you can use (or equivalently, a
flag to do what you need, but I think the idea is to not have such a
flag).
i.e. even if you used the custom target JSON, we would still need to
ask, since the goal is to remove that script entirely.
Thanks!
Cheers,
Miguel
I think disabling altivec, fp and vsx with compiler flag will work.
What is your opinion on this?
Regards,
Mukesh
On Sun, Feb 22, 2026 at 08:11:17PM +0100, Miguel Ojeda wrote:
On Sun, Feb 22, 2026 at 8:07 PM Link Mauve [off-list ref] wrote:
quoted
Should we come back to describing the target like I did in my first
patch[1] in scripts/generate_rust_target.rs, or should I bring that to
Rust to create a powerpc-unknown-unknown-softfloat target upstream? Or
is there a better third solution I’m not thinking of?
We are trying to stop using the custom target specs, so we should ask
upstream to give you a built-in target you can use (or equivalently, a
flag to do what you need, but I think the idea is to not have such a
flag).
i.e. even if you used the custom target JSON, we would still need to
ask, since the goal is to remove that script entirely.
Thanks!
Cheers,
Miguel
Sorry for the spam, my earlier message got rejected.
I think, disabling altivec, fpu and vsx with compiler flag will work.
What are your opinion on this?
Regards,
Mukesh
From: Alice Ryhl <aliceryhl@google.com> Date: 2026-02-23 09:22:36
On Mon, Feb 23, 2026 at 07:56:02AM +0530, Mukesh Kumar Chaurasiya wrote:
On Sun, Feb 22, 2026 at 08:11:17PM +0100, Miguel Ojeda wrote:
quoted
On Sun, Feb 22, 2026 at 8:07 PM Link Mauve [off-list ref] wrote:
quoted
Should we come back to describing the target like I did in my first
patch[1] in scripts/generate_rust_target.rs, or should I bring that to
Rust to create a powerpc-unknown-unknown-softfloat target upstream? Or
is there a better third solution I’m not thinking of?
We are trying to stop using the custom target specs, so we should ask
upstream to give you a built-in target you can use (or equivalently, a
flag to do what you need, but I think the idea is to not have such a
flag).
i.e. even if you used the custom target JSON, we would still need to
ask, since the goal is to remove that script entirely.
I think, disabling altivec, fpu and vsx with compiler flag will work.
What are your opinion on this?
I think you can and should submit a PR to add a softfloat target to
upstream Rust right now, and I believe there should be no issue in
accepting that.
If there's a workaround we can use on existing compiler versions without
the target, that's great too, but we should get the target in upstream
asap.
Alice
From: Miguel Ojeda <hidden> Date: 2026-02-23 15:31:49
On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
[off-list ref] wrote:
I think, disabling altivec, fpu and vsx with compiler flag will work.
What are your opinion on this?
It is really up to upstream Rust -- for us, i.e. the kernel, it
usually doesn't really matter much how things like that are
accomplished: whether via flags, a built-in target, a custom target,
etc. However, we need to know what the path to stability is.
My understanding (but I may be wrong) is that upstream Rust prefer we
use built-in targets for softfloat instead of disabling via
`-Ctarget-feature` (and that the other options may go away soon and/or
will never be stable) -- at least for some cases. For instance, for
arm64, please this recent change kernel-side regarding `neon` as an
entry point:
446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
So please ask upstream Rust (probably in their Zulip, e.g. in
t-compiler or rust-for-linux channels) what you should do for powerpc.
They will likely be happy with a PR adding the target (or whatever
they decide) as Alice mentions. And until we reach that minimum
version (in a year or more), we can use something else meanwhile. But
at least we will have a way towards the end goal, if that makes sense.
In case it helps, let me Cc Ralf, Jubilee and Matthew who were
involved in some of that discussion in the past, plus the compiler
leads.
Cheers,
Miguel
On Mon, Feb 23, 2026 at 09:22:33AM +0000, Alice Ryhl wrote:
On Mon, Feb 23, 2026 at 07:56:02AM +0530, Mukesh Kumar Chaurasiya wrote:
quoted
On Sun, Feb 22, 2026 at 08:11:17PM +0100, Miguel Ojeda wrote:
quoted
On Sun, Feb 22, 2026 at 8:07 PM Link Mauve [off-list ref] wrote:
quoted
Should we come back to describing the target like I did in my first
patch[1] in scripts/generate_rust_target.rs, or should I bring that to
Rust to create a powerpc-unknown-unknown-softfloat target upstream? Or
is there a better third solution I’m not thinking of?
We are trying to stop using the custom target specs, so we should ask
upstream to give you a built-in target you can use (or equivalently, a
flag to do what you need, but I think the idea is to not have such a
flag).
i.e. even if you used the custom target JSON, we would still need to
ask, since the goal is to remove that script entirely.
I think, disabling altivec, fpu and vsx with compiler flag will work.
What are your opinion on this?
I think you can and should submit a PR to add a softfloat target to
upstream Rust right now, and I believe there should be no issue in
accepting that.
If there's a workaround we can use on existing compiler versions without
the target, that's great too, but we should get the target in upstream
asap.
On Mon, Feb 23, 2026 at 04:31:36PM +0100, Miguel Ojeda wrote:
On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
[off-list ref] wrote:
quoted
I think, disabling altivec, fpu and vsx with compiler flag will work.
What are your opinion on this?
It is really up to upstream Rust -- for us, i.e. the kernel, it
usually doesn't really matter much how things like that are
accomplished: whether via flags, a built-in target, a custom target,
etc. However, we need to know what the path to stability is.
My understanding (but I may be wrong) is that upstream Rust prefer we
use built-in targets for softfloat instead of disabling via
`-Ctarget-feature` (and that the other options may go away soon and/or
will never be stable) -- at least for some cases. For instance, for
arm64, please this recent change kernel-side regarding `neon` as an
entry point:
446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
Aah, that makes it clearer.
So please ask upstream Rust (probably in their Zulip, e.g. in
t-compiler or rust-for-linux channels) what you should do for powerpc.
They will likely be happy with a PR adding the target (or whatever
they decide) as Alice mentions. And until we reach that minimum
version (in a year or more), we can use something else meanwhile. But
at least we will have a way towards the end goal, if that makes sense.
Yeah makes sense. Will work towards this.
Regards,
Mukesh
In case it helps, let me Cc Ralf, Jubilee and Matthew who were
involved in some of that discussion in the past, plus the compiler
leads.
Cheers,
Miguel
On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
[off-list ref] wrote:
quoted
I think, disabling altivec, fpu and vsx with compiler flag will work.
What are your opinion on this?
It is really up to upstream Rust -- for us, i.e. the kernel, it
usually doesn't really matter much how things like that are
accomplished: whether via flags, a built-in target, a custom target,
etc. However, we need to know what the path to stability is.
My understanding (but I may be wrong) is that upstream Rust prefer we
use built-in targets for softfloat instead of disabling via
`-Ctarget-feature` (and that the other options may go away soon and/or
will never be stable) -- at least for some cases. For instance, for
arm64, please this recent change kernel-side regarding `neon` as an
entry point:
446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
So please ask upstream Rust (probably in their Zulip, e.g. in
t-compiler or rust-for-linux channels) what you should do for powerpc.
They will likely be happy with a PR adding the target (or whatever
they decide) as Alice mentions. And until we reach that minimum
version (in a year or more), we can use something else meanwhile. But
at least we will have a way towards the end goal, if that makes sense.
In case it helps, let me Cc Ralf, Jubilee and Matthew who were
involved in some of that discussion in the past, plus the compiler
leads.
Upstream Rust dev here. Indeed we'd strongly prefer if this could use a built-in
Rust target; we can work with you on adding a new target if that is needed.
The kernel currently uses a custom JSON target on x86 and that's quite the
headache for compiler development: JSON targets are highly unstable and directly
expose low-level details of how the compiler internally represents targets. When
we change that representation, we update all built-in targets, but of course we
cannot update JSON targets. So whenever possible we'd like to move towards
reducing the number of JSON targets used by the kernel, not increase it. :)
Kind regards,
Ralf
On Tue, Feb 24, 2026 at 09:58:10AM +0100, Ralf Jung wrote:
Hi all,
On 23.02.26 16:31, Miguel Ojeda wrote:
quoted
On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
[off-list ref] wrote:
quoted
I think, disabling altivec, fpu and vsx with compiler flag will work.
What are your opinion on this?
It is really up to upstream Rust -- for us, i.e. the kernel, it
usually doesn't really matter much how things like that are
accomplished: whether via flags, a built-in target, a custom target,
etc. However, we need to know what the path to stability is.
My understanding (but I may be wrong) is that upstream Rust prefer we
use built-in targets for softfloat instead of disabling via
`-Ctarget-feature` (and that the other options may go away soon and/or
will never be stable) -- at least for some cases. For instance, for
arm64, please this recent change kernel-side regarding `neon` as an
entry point:
446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
So please ask upstream Rust (probably in their Zulip, e.g. in
t-compiler or rust-for-linux channels) what you should do for powerpc.
They will likely be happy with a PR adding the target (or whatever
they decide) as Alice mentions. And until we reach that minimum
version (in a year or more), we can use something else meanwhile. But
at least we will have a way towards the end goal, if that makes sense.
In case it helps, let me Cc Ralf, Jubilee and Matthew who were
involved in some of that discussion in the past, plus the compiler
leads.
Upstream Rust dev here. Indeed we'd strongly prefer if this could use a
built-in Rust target; we can work with you on adding a new target if that is
needed.
The kernel currently uses a custom JSON target on x86 and that's quite the
headache for compiler development: JSON targets are highly unstable and
directly expose low-level details of how the compiler internally represents
targets. When we change that representation, we update all built-in targets,
but of course we cannot update JSON targets. So whenever possible we'd like
to move towards reducing the number of JSON targets used by the kernel, not
increase it. :)
Kind regards,
Ralf
Hey,
Sorry for delayed response. I was out of network zone.
I am not sure about the process of how to get this in rust toolchain.
Should I raise an issue of github for this?
Regards,
Mukesh
From: Alice Ryhl <aliceryhl@google.com> Date: 2026-03-02 07:29:27
On Mon, Mar 02, 2026 at 11:25:54AM +0530, Mukesh Kumar Chaurasiya wrote:
On Tue, Feb 24, 2026 at 09:58:10AM +0100, Ralf Jung wrote:
quoted
Hi all,
On 23.02.26 16:31, Miguel Ojeda wrote:
quoted
On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
[off-list ref] wrote:
quoted
I think, disabling altivec, fpu and vsx with compiler flag will work.
What are your opinion on this?
It is really up to upstream Rust -- for us, i.e. the kernel, it
usually doesn't really matter much how things like that are
accomplished: whether via flags, a built-in target, a custom target,
etc. However, we need to know what the path to stability is.
My understanding (but I may be wrong) is that upstream Rust prefer we
use built-in targets for softfloat instead of disabling via
`-Ctarget-feature` (and that the other options may go away soon and/or
will never be stable) -- at least for some cases. For instance, for
arm64, please this recent change kernel-side regarding `neon` as an
entry point:
446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
So please ask upstream Rust (probably in their Zulip, e.g. in
t-compiler or rust-for-linux channels) what you should do for powerpc.
They will likely be happy with a PR adding the target (or whatever
they decide) as Alice mentions. And until we reach that minimum
version (in a year or more), we can use something else meanwhile. But
at least we will have a way towards the end goal, if that makes sense.
In case it helps, let me Cc Ralf, Jubilee and Matthew who were
involved in some of that discussion in the past, plus the compiler
leads.
Upstream Rust dev here. Indeed we'd strongly prefer if this could use a
built-in Rust target; we can work with you on adding a new target if that is
needed.
The kernel currently uses a custom JSON target on x86 and that's quite the
headache for compiler development: JSON targets are highly unstable and
directly expose low-level details of how the compiler internally represents
targets. When we change that representation, we update all built-in targets,
but of course we cannot update JSON targets. So whenever possible we'd like
to move towards reducing the number of JSON targets used by the kernel, not
increase it. :)
Kind regards,
Ralf
Hey,
Sorry for delayed response. I was out of network zone.
I am not sure about the process of how to get this in rust toolchain.
Should I raise an issue of github for this?
You would need to add a new file to compiler/rustc_target/src/spec/targets
in the rustc repository.
If you're not sure what to put there, I would suggest coming up with
something that looks plausible, and opening a PR with that. Then others
can help you with filling out the target correctly.
Alice
On Mon, Mar 02, 2026 at 11:25:54AM +0530, Mukesh Kumar Chaurasiya wrote:
quoted
On Tue, Feb 24, 2026 at 09:58:10AM +0100, Ralf Jung wrote:
quoted
Hi all,
On 23.02.26 16:31, Miguel Ojeda wrote:
quoted
On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
[off-list ref] wrote:
quoted
I think, disabling altivec, fpu and vsx with compiler flag will work.
What are your opinion on this?
It is really up to upstream Rust -- for us, i.e. the kernel, it
usually doesn't really matter much how things like that are
accomplished: whether via flags, a built-in target, a custom target,
etc. However, we need to know what the path to stability is.
My understanding (but I may be wrong) is that upstream Rust prefer we
use built-in targets for softfloat instead of disabling via
`-Ctarget-feature` (and that the other options may go away soon and/or
will never be stable) -- at least for some cases. For instance, for
arm64, please this recent change kernel-side regarding `neon` as an
entry point:
446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
So please ask upstream Rust (probably in their Zulip, e.g. in
t-compiler or rust-for-linux channels) what you should do for powerpc.
They will likely be happy with a PR adding the target (or whatever
they decide) as Alice mentions. And until we reach that minimum
version (in a year or more), we can use something else meanwhile. But
at least we will have a way towards the end goal, if that makes sense.
In case it helps, let me Cc Ralf, Jubilee and Matthew who were
involved in some of that discussion in the past, plus the compiler
leads.
Upstream Rust dev here. Indeed we'd strongly prefer if this could use a
built-in Rust target; we can work with you on adding a new target if that is
needed.
The kernel currently uses a custom JSON target on x86 and that's quite the
headache for compiler development: JSON targets are highly unstable and
directly expose low-level details of how the compiler internally represents
targets. When we change that representation, we update all built-in targets,
but of course we cannot update JSON targets. So whenever possible we'd like
to move towards reducing the number of JSON targets used by the kernel, not
increase it. :)
Kind regards,
Ralf
Hey,
Sorry for delayed response. I was out of network zone.
I am not sure about the process of how to get this in rust toolchain.
Should I raise an issue of github for this?
You would need to add a new file to compiler/rustc_target/src/spec/targets
in the rustc repository.
If you're not sure what to put there, I would suggest coming up with
something that looks plausible, and opening a PR with that. Then others
can help you with filling out the target correctly.
On 2/10/26 2:30 PM, Mukesh Kumar Chaurasiya (IBM) wrote:
Enable experimental rust support for ppc64le and ppc32be. The patch for
ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been
merged over it. ppc32 needs some toolchain fixes mentioned in the patch
`rust: Add PowerPC support` and the discussion for that is done here[1].
This has been tested on powernv9 hardware and power10 pseries qemu. I
I request Link to test the ppc32 part as i don't have a hardware to test
it out.
[1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr
[2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com
Could see these build issues with the Rust patchset in the compilation
of powerpc-next-test
This happens when compilation happens only with few threads
# rustc --version
rustc 1.94.0 (4a4ef493e 2026-03-02)
....
EXPORTS rust/exports_core_generated.h
BINDGEN rust/bindings/bindings_generated.rs
BINDGEN rust/bindings/bindings_helpers_generated.rs
CC rust/helpers/helpers.o
EXPORTS rust/exports_helpers_generated.h
RUSTC L rust/compiler_builtins.o
RUSTC L rust/ffi.o
RUSTC PL rust/libproc_macro2.rlib
error[E0464]: multiple candidates for `rmeta` dependency `core` found
--> rust/proc-macro2/marker.rs:4:5
|
4 | use core::marker::PhantomData;
| ^^^^
|
= note: candidate #1:
/root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/powerpc64le-unknown-linux-gnu/lib/libcore-951759db375eea0c.rmeta
= note: candidate #2: ./rust/libcore.rmeta
error[E0119]: conflicting implementations of trait `PartialEq` for type
`fallback::Ident`
--> rust/proc-macro2/fallback.rs:875:1
|
869 | impl PartialEq for Ident {
| ------------------------ first implementation here
...
875 | / impl<T> PartialEq<T> for Ident
876 | | where
877 | | T: ?Sized + AsRef<str>,
| |___________________________^ conflicting implementation for
`fallback::Ident`
error[E0277]: `LexError` doesn't implement `std::fmt::Display`
--> rust/proc-macro2/lib.rs:347:16
|
347 | impl Error for LexError {}
| ^^^^^^^^ unsatisfied trait bound
|
help: the trait `std::fmt::Display` is not implemented for `LexError`
--> rust/proc-macro2/lib.rs:204:1
|
204 | pub struct LexError {
| ^^^^^^^^^^^^^^^^^^^
note: required by a bound in `std::error::Error`
-->
/root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/error.rs:59:26
|
59 | pub trait Error: Debug + Display {
| ^^^^^^^ required by this bound in `Error`
error[E0277]: `LexError` doesn't implement `Debug`
--> rust/proc-macro2/lib.rs:347:16
|
347 | impl Error for LexError {}
| ^^^^^^^^ unsatisfied trait bound
|
help: the trait `Debug` is not implemented for `LexError`
--> rust/proc-macro2/lib.rs:204:1
|
204 | pub struct LexError {
| ^^^^^^^^^^^^^^^^^^^
= note: add `#[derive(Debug)]` to `LexError` or manually `impl
Debug for LexError`
note: required by a bound in `std::error::Error`
-->
/root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/error.rs:59:18
|
59 | pub trait Error: Debug + Display {
| ^^^^^ required by this bound in `Error`
error: aborting due to 4 previous errors
......
But when parallelized with more threads (-j 128) compilation passes with
out any error
There is some ordering of libcore is messing up I guess (I could be wrong)
(I have removed the warning of unstable features messages here for
cleaner output)
....
VDSO64SYM include/generated/vdso64-offsets.h
RUSTC L rust/core.o
BINDGEN rust/bindings/bindings_generated.rs
BINDGEN rust/bindings/bindings_helpers_generated.rs
CC rust/helpers/helpers.o
RUSTC PL rust/libproc_macro2.rlib
BINDGEN rust/uapi/uapi_generated.rs
RSCPP rust/kernel/generated_arch_static_branch_asm.rs
RSCPP rust/kernel/generated_arch_warn_asm.rs
RSCPP rust/kernel/generated_arch_reachable_asm.rs
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:5:9: warning:
'_IOC_SIZEBITS' macro redefined [-Wmacro-redefined]
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:6:9: warning:
'_IOC_DIRBITS' macro redefined [-Wmacro-redefined]
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:8:9: warning:
'_IOC_NONE' macro redefined [-Wmacro-redefined]
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:10:9: warning:
'_IOC_WRITE' macro redefined [-Wmacro-redefined]
EXPORTS rust/exports_helpers_generated.h
RUSTC PL rust/libquote.rlib
RUSTC PL rust/libsyn.rlib
RUSTC P rust/libpin_init_internal.so
RUSTC P rust/libmacros.so
EXPORTS rust/exports_core_generated.h
RUSTC L rust/compiler_builtins.o
RUSTC L rust/ffi.o
RUSTC L rust/pin_init.o
RUSTC L rust/build_error.o
RUSTC L rust/bindings.o
RUSTC L rust/uapi.o
EXPORTS rust/exports_bindings_generated.h
RUSTC L rust/kernel.o
EXPORTS rust/exports_kernel_generated.h
LDS scripts/module.lds
HOSTCC usr/gen_init_cpio
CC init/main.o
....
Also I see some errors when compiling modules. I am looking at these and
any help is welcome.
I will pull out Rust patches for now from powerpc-linux next-test branch
and once this is
restored I will add these patches back to branch for the merge.
Maddy
Changelog:
V5 -> V6:
- Added a missing Tested by from Venkat which got missed since V3
- Support is marked as Maintained instead of experimental
V5: https://lore.kernel.org/all/20260210053756.2088302-1-mkchauras@gmail.com
V4 -> V5:
- Removed a nested ifdef from PPC64 for Little endian toolchain
V4: https://lore.kernel.org/all/20260209105456.1551677-1-mkchauras@gmail.com
V3 -> V4:
- Co-developed-by header added in patch 1
V3: https://lore.kernel.org/all/20260205180429.3280657-1-mkchauras@gmail.com
V2 -> V3:
- Splited HAVE_RUST in 2 lines
- BINDGEN_TARGET_powerpc initialized before assigning the same to
BINDGEN_TARGET
V2: https://lore.kernel.org/all/20260204210125.613350-1-mkchauras@gmail.com
V1 -> V2:
- jump label fix for rust has been moved to a separate patch
- PPC32 support has been taken
- rust support has been marked experimental
- target.json dependency has been removed
- HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64
Link Mauve (1):
rust: Add PowerPC support
Mukesh Kumar Chaurasiya (IBM) (2):
powerpc/jump_label: adjust inline asm to be consistent
powerpc: Enable Rust for ppc64le
Documentation/rust/arch-support.rst | 1 +
arch/powerpc/Kconfig | 2 ++
arch/powerpc/Makefile | 7 +++++++
arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
rust/Makefile | 10 +++++++++-
5 files changed, 32 insertions(+), 11 deletions(-)
On Wed, Mar 25, 2026 at 01:59:55PM +0530, Madhavan Srinivasan wrote:
On 2/10/26 2:30 PM, Mukesh Kumar Chaurasiya (IBM) wrote:
quoted
Enable experimental rust support for ppc64le and ppc32be. The patch for
ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been
merged over it. ppc32 needs some toolchain fixes mentioned in the patch
`rust: Add PowerPC support` and the discussion for that is done here[1].
This has been tested on powernv9 hardware and power10 pseries qemu. I
I request Link to test the ppc32 part as i don't have a hardware to test
it out.
[1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr
[2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com
Could see these build issues with the Rust patchset in the compilation of
powerpc-next-test
This happens when compilation happens only with few threads
# rustc --version
rustc 1.94.0 (4a4ef493e 2026-03-02)
....
EXPORTS rust/exports_core_generated.h
BINDGEN rust/bindings/bindings_generated.rs
BINDGEN rust/bindings/bindings_helpers_generated.rs
CC rust/helpers/helpers.o
EXPORTS rust/exports_helpers_generated.h
RUSTC L rust/compiler_builtins.o
RUSTC L rust/ffi.o
RUSTC PL rust/libproc_macro2.rlib
error[E0464]: multiple candidates for `rmeta` dependency `core` found
--> rust/proc-macro2/marker.rs:4:5
|
4 | use core::marker::PhantomData;
| ^^^^
|
= note: candidate #1: /root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/powerpc64le-unknown-linux-gnu/lib/libcore-951759db375eea0c.rmeta
= note: candidate #2: ./rust/libcore.rmeta
error[E0119]: conflicting implementations of trait `PartialEq` for type
`fallback::Ident`
--> rust/proc-macro2/fallback.rs:875:1
|
869 | impl PartialEq for Ident {
| ------------------------ first implementation here
...
875 | / impl<T> PartialEq<T> for Ident
876 | | where
877 | | T: ?Sized + AsRef<str>,
| |___________________________^ conflicting implementation for
`fallback::Ident`
error[E0277]: `LexError` doesn't implement `std::fmt::Display`
--> rust/proc-macro2/lib.rs:347:16
|
347 | impl Error for LexError {}
| ^^^^^^^^ unsatisfied trait bound
|
help: the trait `std::fmt::Display` is not implemented for `LexError`
--> rust/proc-macro2/lib.rs:204:1
|
204 | pub struct LexError {
| ^^^^^^^^^^^^^^^^^^^
note: required by a bound in `std::error::Error`
--> /root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/error.rs:59:26
|
59 | pub trait Error: Debug + Display {
| ^^^^^^^ required by this bound in `Error`
error[E0277]: `LexError` doesn't implement `Debug`
--> rust/proc-macro2/lib.rs:347:16
|
347 | impl Error for LexError {}
| ^^^^^^^^ unsatisfied trait bound
|
help: the trait `Debug` is not implemented for `LexError`
--> rust/proc-macro2/lib.rs:204:1
|
204 | pub struct LexError {
| ^^^^^^^^^^^^^^^^^^^
= note: add `#[derive(Debug)]` to `LexError` or manually `impl Debug for
LexError`
note: required by a bound in `std::error::Error`
--> /root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/error.rs:59:18
|
59 | pub trait Error: Debug + Display {
| ^^^^^ required by this bound in `Error`
error: aborting due to 4 previous errors
......
But when parallelized with more threads (-j 128) compilation passes with out
any error
There is some ordering of libcore is messing up I guess (I could be wrong)
(I have removed the warning of unstable features messages here for cleaner
output)
....
VDSO64SYM include/generated/vdso64-offsets.h
RUSTC L rust/core.o
BINDGEN rust/bindings/bindings_generated.rs
BINDGEN rust/bindings/bindings_helpers_generated.rs
CC rust/helpers/helpers.o
RUSTC PL rust/libproc_macro2.rlib
BINDGEN rust/uapi/uapi_generated.rs
RSCPP rust/kernel/generated_arch_static_branch_asm.rs
RSCPP rust/kernel/generated_arch_warn_asm.rs
RSCPP rust/kernel/generated_arch_reachable_asm.rs
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:5:9: warning:
'_IOC_SIZEBITS' macro redefined [-Wmacro-redefined]
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:6:9: warning:
'_IOC_DIRBITS' macro redefined [-Wmacro-redefined]
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:8:9: warning:
'_IOC_NONE' macro redefined [-Wmacro-redefined]
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:10:9: warning:
'_IOC_WRITE' macro redefined [-Wmacro-redefined]
EXPORTS rust/exports_helpers_generated.h
RUSTC PL rust/libquote.rlib
RUSTC PL rust/libsyn.rlib
RUSTC P rust/libpin_init_internal.so
RUSTC P rust/libmacros.so
EXPORTS rust/exports_core_generated.h
RUSTC L rust/compiler_builtins.o
RUSTC L rust/ffi.o
RUSTC L rust/pin_init.o
RUSTC L rust/build_error.o
RUSTC L rust/bindings.o
RUSTC L rust/uapi.o
EXPORTS rust/exports_bindings_generated.h
RUSTC L rust/kernel.o
EXPORTS rust/exports_kernel_generated.h
LDS scripts/module.lds
HOSTCC usr/gen_init_cpio
CC init/main.o
....
Also I see some errors when compiling modules. I am looking at these and any
help is welcome.
I will pull out Rust patches for now from powerpc-linux next-test branch and
once this is
restored I will add these patches back to branch for the merge.
Maddy
Aah this happens because core.o is compiled before libproc_macro2.rlib
starts compiling. Once the core.o is compiled it generates the
libcore.rmeta, leading to conflict in two libcore.rmeta available.
I can think of 2 solutions here for this,
1. We can make the libproc_macro2.rlib libquote.rlib libsyn.rlib compile
befor the core.o is compiled OR
2. We can force these to use the toolchain core's metadata and not look
into the kernel's rust directory.
I am still not able to figure out why this is not happening for x86.
What should we do in this case?
Regards,
Mukesh
quoted
Changelog:
V5 -> V6:
- Added a missing Tested by from Venkat which got missed since V3
- Support is marked as Maintained instead of experimental
V5: https://lore.kernel.org/all/20260210053756.2088302-1-mkchauras@gmail.com
V4 -> V5:
- Removed a nested ifdef from PPC64 for Little endian toolchain
V4: https://lore.kernel.org/all/20260209105456.1551677-1-mkchauras@gmail.com
V3 -> V4:
- Co-developed-by header added in patch 1
V3: https://lore.kernel.org/all/20260205180429.3280657-1-mkchauras@gmail.com
V2 -> V3:
- Splited HAVE_RUST in 2 lines
- BINDGEN_TARGET_powerpc initialized before assigning the same to
BINDGEN_TARGET
V2: https://lore.kernel.org/all/20260204210125.613350-1-mkchauras@gmail.com
V1 -> V2:
- jump label fix for rust has been moved to a separate patch
- PPC32 support has been taken
- rust support has been marked experimental
- target.json dependency has been removed
- HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64
Link Mauve (1):
rust: Add PowerPC support
Mukesh Kumar Chaurasiya (IBM) (2):
powerpc/jump_label: adjust inline asm to be consistent
powerpc: Enable Rust for ppc64le
Documentation/rust/arch-support.rst | 1 +
arch/powerpc/Kconfig | 2 ++
arch/powerpc/Makefile | 7 +++++++
arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
rust/Makefile | 10 +++++++++-
5 files changed, 32 insertions(+), 11 deletions(-)