On Wed, Feb 04, 2026 at 04:05:04AM +0100, Link Mauve wrote:
> 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.

Super cool!

> 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.

Uh oh this seems tricky. How is this not a problem on arm32 too?

Perhaps we should just be providing __udivdi3() and __umoddi3() in
general?

> diff --git a/arch/powerpc/include/asm/jump_label.h 
> b/arch/powerpc/include/asm/jump_label.h
> index d4eaba459a0e..238f0f625a36 100644
> --- a/arch/powerpc/include/asm/jump_label.h
> +++ b/arch/powerpc/include/asm/jump_label.h
> @@ -15,14 +15,18 @@
>  #define JUMP_ENTRY_TYPE              stringify_in_c(FTR_ENTRY_LONG)
>  #define JUMP_LABEL_NOP_SIZE  4
>  
> +/* This macro is also expanded on the Rust side. */
> +#define ARCH_STATIC_BRANCH_ASM(key, label)           \
> +     "1:\n\t"                                        \
> +     "nop # arch_static_branch\n\t"                  \
> +     ".pushsection __jump_table,  \"aw\"\n\t"        \
> +     ".long 1b - ., " label " - .\n\t"               \
> +      JUMP_ENTRY_TYPE key " - .\n\t"                 \
> +      ".popsection \n\t"
> +
>  static __always_inline bool arch_static_branch(struct static_key *key, bool 
> branch)
>  {
> -     asm goto("1:\n\t"
> -              "nop # arch_static_branch\n\t"
> -              ".pushsection __jump_table,  \"aw\"\n\t"
> -              ".long 1b - ., %l[l_yes] - .\n\t"
> -              JUMP_ENTRY_TYPE "%c0 - .\n\t"
> -              ".popsection \n\t"
> +     asm goto(ARCH_STATIC_BRANCH_ASM("%c0", "%l[l_yes]")
>                : :  "i" (&((char *)key)[branch]) : : l_yes);

In case this patch takes a long time to land, it may make sense to split
this part out in a separate patch that can land now.

Also, consider pre-emptively updating arch_static_branch_jump too. We
probably need it at some point in the future.

> diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
> index 38b3416bb979..0054880ba0ea 100644
> --- a/scripts/generate_rust_target.rs
> +++ b/scripts/generate_rust_target.rs
> @@ -188,6 +188,16 @@ fn main() {
>          panic!("arm uses the builtin rustc target");
>      } else if cfg.has("ARM64") {
>          panic!("arm64 uses the builtin rustc aarch64-unknown-none target");
> +    } else if cfg.has("PPC32") {
> +        ts.push("arch", "powerpc");
> +        ts.push("data-layout", "E-m:e-p:32:32-Fn32-i64:64-n32");
> +        ts.push("features", "+soft-float");
> +        ts.push("llvm-target", "powerpc-unknown-eabi");
> +        if cfg.rustc_version_atleast(1, 91, 0) {
> +            ts.push("target-pointer-width", 32);
> +        } else {
> +            ts.push("target-pointer-width", "32");
> +        }

Is there no built-in target we can use? I think we want to avoid adding
new targets if at all possible.

Alice

Reply via email to