[PATCH 0/4] Rust for Linux for ppc64le

Hi all,

Here's a first attempt at getting the kernel Rust support building on powerpc.

It's powerpc64le only for now, as that's what I can easily test given the
distros I have installed. Though powerpc and powerpc64 are also Tier 2 platforms
so in theory should work. Supporting those would require something more
complicated than just pointing rustc at arch/$(ARCH)/rust/target.json.

This is based on 832575d934a2 from the Rust-for-Linux tree. Anything newer gives
me errors about symbol name lengths. I figured I'd send this anyway, as it seems
like those errors are probably not powerpc specific.

I'm not sure that all the values in target.json are correct, or required (or if
any are missing), but what I have there seems to work. Would be happy for
someone to scrutinise it though.

Example output:

  # uname -r
  5.12.0-rc3-47689-ge4e12dd7cb75
  # uname -m
  ppc64le
  # modprobe rust_example
   Rust Example (init)
   Am I built-in? false
   Parameters:
     my_bool:    true
     my_i32:     42
     my_str:     default str val
     my_usize:   42
     my_array:   [0, 1]
   Value: 10
   Value: 10
   Large array has length: 514
   modprobe (1589) used greatest stack depth: 6800 bytes left
  # modprobe rust_example_2
   [2] Rust Example (init)
   [2] Am I built-in? false
   [2] Parameters:
   [2]   my_bool:    true
   [2]   my_i32:     42
   [2]   my_str:     default str val
   [2]   my_usize:   42
   [2]   my_array:   [0, 1]
   Large array has length: 1028
   modprobe (1593) used greatest stack depth: 3680 bytes left
  # modprobe rust_example_3
   [3] Rust Example (init)
   [3] Am I built-in? false
   [3] Parameters:
   [3]   my_bool:    true
   [3]   my_i32:     42
   [3]   my_str:     default str val
   [3]   my_usize:   42
   [3]   my_array:   [0, 1]
   Large array has length: 1028
  # modprobe rust_example_4
   [4] Rust Example (init)
   [4] Am I built-in? false
   [4] Parameters:
   [4]   my_bool:    true
   [4]   my_i32:     42
   [4]   my_str:     default str val
   [4]   my_usize:   42
   [4]   my_array:   [0, 1]
   Large array has length: 1028

cheers


Michael Ellerman (4):
  rust: Export symbols in initialized data section
  rust: Add powerpc64 as a 64-bit target_arch in c_types.rs
  powerpc/rust: Add target.json for ppc64le
  rust: Enable for ppc64le

 arch/powerpc/rust/target.json | 30 ++++++++++++++++++++++++++++++
 init/Kconfig                  |  2 +-
 rust/Makefile                 |  2 +-
 rust/kernel/c_types.rs        |  2 +-
 4 files changed, 33 insertions(+), 3 deletions(-)
 create mode 100644 arch/powerpc/rust/target.json


base-commit: 832575d934a2bc5e2fd0aa881d8e6b64bf062fd2
-- 
2.25.1

powerpc kernel code uses int-ll64.h.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 rust/kernel/c_types.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/c_types.rs b/rust/kernel/c_types.rs
index 423ac1108ddb..988fd84b0d66 100644
--- a/rust/kernel/c_types.rs
+++ b/rust/kernel/c_types.rs

@@ -60,7 +60,7 @@ mod c {
     pub type c_size_t = usize;
 }
 
-#[cfg(any(target_arch = "aarch64", target_arch = "x86_64"))]
+#[cfg(any(target_arch = "aarch64", target_arch = "x86_64", target_arch = "powerpc64"))]
 mod c {
     /// C `void` type.
     pub type c_void = core::ffi::c_void;

-- 
2.25.1

On powerpc some symbols end up in the initialized data section, which
means they aren't detected by the logic in cmd_export, leading to errors
such as:

  ERROR: modpost: "_RNvNtCsbDqzXfLQacH_6kernel12module_param15PARAM_OPS_USIZE" [drivers/char/rust_example_4.ko] undefined!

nm represents the "initialized data section" with "D", so also look for
that when exporting symbols.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 rust/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/Makefile b/rust/Makefile
index eb8f12ce1644..4cddae9d4a25 100644
--- a/rust/Makefile
+++ b/rust/Makefile

@@ -73,7 +73,7 @@ $(objtree)/rust/bindings_generated.rs: $(srctree)/rust/kernel/bindings_helper.h
 quiet_cmd_exports = EXPORTS $@
       cmd_exports = \
 	$(NM) -p --defined-only $< \
-		| grep -E ' (T|R) ' | cut -d ' ' -f 3 | grep -E '^(__rust_|_R)' \
+		| grep -E ' (T|R|D) ' | cut -d ' ' -f 3 | grep -E '^(__rust_|_R)' \
 		| xargs -n1 -Isymbol \
 		echo 'EXPORT_SYMBOL$(exports_target_type)(symbol);' > $@
 

-- 
2.25.1

All the pieces are in place now for us to enable building rust support
on ppc64le.

Only works with clang for now.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 init/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/init/Kconfig b/init/Kconfig
index d73ac9de186d..ddc2fda1a22c 100644
--- a/init/Kconfig
+++ b/init/Kconfig

@@ -58,7 +58,7 @@ config LLD_VERSION
 	default 0
 
 config HAS_RUST
-	depends on ARM64 || X86_64
+	depends on ARM64 || X86_64 || (PPC64 && CPU_LITTLE_ENDIAN && CC_IS_CLANG)
 	def_bool $(success,$(RUSTC) --version)
 
 config RUSTC_VERSION

-- 
2.25.1

Based on the x86 and arm64 versions, as well as output from:

  $ rustc +nightly -Z unstable-options --target=powerpc64le-unknown-linux-gnu --print target-spec-json

Notably disables altivec, vsx and hard-float.

The very cryptic data-layout:

  "data-layout": "e-m:e-i64:64-n32:64-S128",

Has the following meaning:

  e:     little endian
  m:e    ELF name mangling
  i64:64 64-bit integers 64-bit aligned
  n32:64 Native integer widths, 32-bit and 64-bit.
  S128   16-byte stack alignment

Those all come from the rustc output, with the exception of the stack
alignment. We obviously do have 8-bit & 16-bit integer types, but I'm
not sure if there's any need to specify that.

ppc64le only for now. We'll eventually need to come up with some way to
change the target.json that's used based on more than just $(ARCH).

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 arch/powerpc/rust/target.json | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 arch/powerpc/rust/target.json

diff --git a/arch/powerpc/rust/target.json b/arch/powerpc/rust/target.json
new file mode 100644
index 000000000000..1e53f8308092
--- /dev/null
+++ b/arch/powerpc/rust/target.json

@@ -0,0 +1,30 @@
+{
+  "arch": "powerpc64",
+  "code-mode": "kernel",
+  "cpu": "ppc64le",
+  "data-layout": "e-m:e-i64:64-n32:64",
+  "env": "gnu",
+  "features": "-altivec,-vsx,-hard-float",
+  "function-sections": false,
+  "is-builtin": true,
+  "linker-flavor": "gcc",
+  "linker-is-gnu": true,
+  "llvm-target": "powerpc64le-elf",
+  "max-atomic-width": 64,
+  "os": "none",
+  "panic-strategy": "abort",
+  "position-independent-executables": true,
+  "pre-link-args": {
+    "gcc": [
+      "-Wl,--as-needed",
+      "-Wl,-z,noexecstack",
+      "-m64"
+    ]
+  },
+  "relocation-model": "static",
+  "relro-level": "full",
+  "target-family": "unix",
+  "target-mcount": "_mcount",
+  "target-endian": "little",
+  "target-pointer-width": "64"
+}

-- 
2.25.1

On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman [off-list ref] wrote:

ppc64le only for now. We'll eventually need to come up with some way to
change the target.json that's used based on more than just $(ARCH).

Indeed, it is one reason I didn't tackle e.g. x86 32-bit, because I
wanted to figure out how to do the whole `target.json` cleanly (i.e.
likely have a script generate them on the fly), so I thought it was
better to wait post-RFC.

Cheers,
Miguel

Hi Michael,

On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman [off-list ref] wrote:

Hi all,

Here's a first attempt at getting the kernel Rust support building on powerpc.

Thanks a *lot*! It is great to have more architectures rolling.

It's powerpc64le only for now, as that's what I can easily test given the
distros I have installed. Though powerpc and powerpc64 are also Tier 2 platforms

Even if it is just 64-bit, it is very good to have it!

so in theory should work. Supporting those would require something more
complicated than just pointing rustc at arch/$(ARCH)/rust/target.json.

Yeah, the arch/$(ARCH)/rust/target.json dance is a placeholder -- I
need to figure out how to do that more cleanly, likely generating them
on the fly.

This is based on 832575d934a2 from the Rust-for-Linux tree. Anything newer gives
me errors about symbol name lengths. I figured I'd send this anyway, as it seems
like those errors are probably not powerpc specific.

Sure, feel free to send things even if they don't work completely.

I will take a look at the symbol name lengths -- I increased that
limit to 512 and added support for 2-byte lengths in the tables, but
perhaps something is missing. If I manage to make it work, I can add
ppc64le to our CI! :-)

Michael Ellerman (4):
  rust: Export symbols in initialized data section
  rust: Add powerpc64 as a 64-bit target_arch in c_types.rs
  powerpc/rust: Add target.json for ppc64le
  rust: Enable for ppc64le

Regarding the development process: at least until the RFC we are
working with the usual GitHub PR workflow (for several reasons: having
a quick CI setup, getting new Rust developers on-board, having a list
of "issues", cross-reference with the Rust repo, etc.).

I can take patches from the list, of course, but since we are pre-RFC,
do you mind if they get rebased etc. through there?

Thanks again!

Cheers,
Miguel

Miguel Ojeda [off-list ref] writes:

Hi Michael,

On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman [off-list ref] wrote:

quoted

Hi all,

Here's a first attempt at getting the kernel Rust support building on powerpc.

Thanks a *lot*! It is great to have more architectures rolling.

No worries.

quoted

It's powerpc64le only for now, as that's what I can easily test given the
distros I have installed. Though powerpc and powerpc64 are also Tier 2 platforms

Even if it is just 64-bit, it is very good to have it!

quoted

so in theory should work. Supporting those would require something more
complicated than just pointing rustc at arch/$(ARCH)/rust/target.json.

Yeah, the arch/$(ARCH)/rust/target.json dance is a placeholder -- I
need to figure out how to do that more cleanly, likely generating them
on the fly.

Yeah that's a good idea. That way they can be made to exactly match the
kernel configuration.

quoted

This is based on 832575d934a2 from the Rust-for-Linux tree. Anything newer gives
me errors about symbol name lengths. I figured I'd send this anyway, as it seems
like those errors are probably not powerpc specific.

Sure, feel free to send things even if they don't work completely.

I will take a look at the symbol name lengths -- I increased that
limit to 512 and added support for 2-byte lengths in the tables, but
perhaps something is missing. If I manage to make it work, I can add
ppc64le to our CI! :-)

It would be nice to be in the CI. I was building natively so I haven't
tried cross compiling yet (which we'll need for CI).

quoted

Michael Ellerman (4):
  rust: Export symbols in initialized data section
  rust: Add powerpc64 as a 64-bit target_arch in c_types.rs
  powerpc/rust: Add target.json for ppc64le
  rust: Enable for ppc64le

Regarding the development process: at least until the RFC we are
working with the usual GitHub PR workflow (for several reasons: having
a quick CI setup, getting new Rust developers on-board, having a list
of "issues", cross-reference with the Rust repo, etc.).

I can take patches from the list, of course, but since we are pre-RFC,
do you mind if they get rebased etc. through there?

No I don't mind at all. I just sent patches so other ppc folks could see
what I had, and it's kind of the process I'm used to.

I can send a pull request if that's easiest.

cheers

On Tue, Mar 23, 2021 at 1:16 PM Michael Ellerman [off-list ref] wrote:

It would be nice to be in the CI. I was building natively so I haven't
tried cross compiling yet (which we'll need for CI).

Indeed -- in the CI we already cross-compile arm64 (and run under QEMU
both arm64 as well as x86_64), so it is easy to add new ones to the
matrix.

I can send a pull request if that's easiest.

No worries, I will pick the patches. But, of course, feel free to join
us in GitHub! :-)

Cheers,
Miguel