std: add support for s390x

[japaric]

depends on rust-lang/libc#377. I need to update the libc submodule after that lands.

r? @alexcrichton

caveats:

• cabi_s390x is a copy paste of mips64
• unwinding is broken:

$ ./panic
thread 'main' panicked at 'Hello, world!', panic.rs:2
note: Run with `RUST_BACKTRACE=1` for a backtrace.
fatal runtime error: failed to initiate panic, error 3
Aborted

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

Hey at least it's a start! Looks good to me modulo the libc updates.

cc @rust-lang/tools, new targets!

[japaric]

Pushed a commit with an update of the libc submodule.

By the way, I've been exchanging e-mails with IBM's Robin and Ulrich, who are also working on this. They pointed me to the LinuxOne program where I got access to s390 hardware and thanks to that I was able to test this 👍 . We exchanged notes (patches, actually :-) about this particular topic (std for s390) and the changes we made on both sides were very similar. Their cabi implementation is slightly different and they are much more knowledgable than me in that area, so their implementation is what we should ultimately use.

@alexcrichton Do you think we should land this first or should we wait for Robin and Ulrich's set of patches (proper cabi, etc.)?

[alexcrichton]

Oh awesome! Thanks Robin and Ulrich!

Yeah let's hold off on landing until we can get a closer scrutiny of the cabi patches.

[uweigand]

unwinding is broken

This turns out to be an ABI problem, actually. The rust_eh_personality routine is miscompiled, it does not extend the return value to occupy the full register, as the ABI requires and the callee in libgcc expects.

Now, the cabi_s390x.rs code does in fact use "extend_integer_width_to", which is supposed to perform that extension. But abi.rs common code ignores this call for types it considers neither signed nor unsigned. This category apparently includes enums, even those that map to a plain integer type in LLVM. The return type of rust_eh_personality just happens to be one such enum type.

In order to comply with C ABI where enum types are passed between C and Rust code, I guess abi.rs should also handle zero-/sign-extensions of enum types that map to a plain integer. This potentially affects other targets beyond s390x as well ...

Not sure if this is at the right level of abstraction, but the following patch makes the "panic" test case work for me:

diff --git a/src/librustc_trans/abi.rs b/src/librustc_trans/abi.rs
index 3a7fde6..fa26ce2 100644
--- a/src/librustc_trans/abi.rs
+++ b/src/librustc_trans/abi.rs
@@ -315,6 +317,12 @@ impl FnType {
                 if ty.is_integral() {
                     arg.signedness = Some(ty.is_signed());
                 }
+                if let ty::TyEnum(..) = ty.sty {
+                    if arg.ty.kind() == llvm::Integer {
+                        let repr = adt::represent_type(ccx, ty);
+                        arg.signedness = Some(adt::is_discr_signed(&repr));
+                    }
+                }
                 if llsize_of_real(ccx, arg.ty) == 0 {
                     // For some forsaken reason, x86_64-pc-windows-gnu
                     // doesn't ignore zero-sized struct arguments.

Oh awesome! Thanks Robin and Ulrich!

You're welcome :-) We really like to see Rust work well on our platform ...

Yeah let's hold off on landing until we can get a closer scrutiny of the cabi patches.

OK, I'll get back with a complete implementation. The main missing piece is handling structs consisting (recursively) of just a single floating-point element. I hope to complete this soon. (While I'm familiar with the ABI, I haven't actually written any Rust code before, so it may take me a bit longer than usual ...)

[alexcrichton]

Oh whoa, nice investigation! If you need any help I may not be able to help you myself but I may be able to point you to someone who can!

[brson]

Exciting stuff.

[uweigand]

I've now opened a separate pull request for the enum ABI problem:
#36321

Once this is resolved, I'll provide an updated PR for the s390x-specific changes. Note that with my latest patch set I was able to complete a native build cycle on s390x-linux:

• build a cross-compiler on x86_64
• using the cross-compiler, cross-build a native compiler
• using the native compiler as stage0, run a native bootstrap
• using the bootstrapped compiler, run "make check" with no failures

[alexcrichton]

@uweigand holy cow that's awesome news! Should we go ahead and land this PR or do you have some pending changes you'd like to merge in as well?

[uweigand]

I'll provide an updated PR once the prerequisites (libc changes, enum ABI) are in, so please hold back on merging this one ...

[japaric]

Closing in favor of #36369