-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add s390x support #36369
Merged
Merged
Add s390x support #36369
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,24 @@ | ||
# rustbuild-only target | ||
# s390x-unknown-linux-gnu configuration | ||
CROSS_PREFIX_s390x-unknown-linux-gnu=s390x-linux-gnu- | ||
CC_s390x-unknown-linux-gnu=$(CC) | ||
CXX_s390x-unknown-linux-gnu=$(CXX) | ||
CPP_s390x-unknown-linux-gnu=$(CPP) | ||
AR_s390x-unknown-linux-gnu=$(AR) | ||
CFG_LIB_NAME_s390x-unknown-linux-gnu=lib$(1).so | ||
CFG_STATIC_LIB_NAME_s390x-unknown-linux-gnu=lib$(1).a | ||
CFG_LIB_GLOB_s390x-unknown-linux-gnu=lib$(1)-*.so | ||
CFG_LIB_DSYM_GLOB_s390x-unknown-linux-gnu=lib$(1)-*.dylib.dSYM | ||
CFG_CFLAGS_s390x-unknown-linux-gnu := -m64 $(CFLAGS) | ||
CFG_GCCISH_CFLAGS_s390x-unknown-linux-gnu := -g -fPIC -m64 $(CFLAGS) | ||
CFG_GCCISH_CXXFLAGS_s390x-unknown-linux-gnu := -fno-rtti $(CXXFLAGS) | ||
CFG_GCCISH_LINK_FLAGS_s390x-unknown-linux-gnu := -shared -fPIC -ldl -pthread -lrt -g -m64 | ||
CFG_GCCISH_DEF_FLAG_s390x-unknown-linux-gnu := -Wl,--export-dynamic,--dynamic-list= | ||
CFG_LLC_FLAGS_s390x-unknown-linux-gnu := | ||
CFG_INSTALL_NAME_s390x-unknown-linux-gnu = | ||
CFG_EXE_SUFFIX_s390x-unknown-linux-gnu = | ||
CFG_WINDOWSY_s390x-unknown-linux-gnu := | ||
CFG_UNIXY_s390x-unknown-linux-gnu := 1 | ||
CFG_LDPATH_s390x-unknown-linux-gnu := | ||
CFG_RUN_s390x-unknown-linux-gnu=$(2) | ||
CFG_RUN_TARG_s390x-unknown-linux-gnu=$(call CFG_RUN_s390x-unknown-linux-gnu,,$(2)) | ||
CFG_GNU_TRIPLE_s390x-unknown-linux-gnu := s390x-unknown-linux-gnu |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Submodule liblibc
updated
10 files
+2 −0 | src/lib.rs | |
+2 −0 | src/unix/notbsd/android/mod.rs | |
+3 −0 | src/unix/notbsd/linux/mips.rs | |
+2 −0 | src/unix/notbsd/linux/mips64.rs | |
+11 −2 | src/unix/notbsd/linux/mod.rs | |
+3 −1 | src/unix/notbsd/linux/musl/b32/mod.rs | |
+4 −1 | src/unix/notbsd/linux/musl/mod.rs | |
+2 −0 | src/unix/notbsd/linux/other/mod.rs | |
+667 −0 | src/unix/notbsd/linux/s390x.rs | |
+0 −2 | src/unix/notbsd/mod.rs |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,150 @@ | ||
// Copyright 2016 The Rust Project Developers. See the COPYRIGHT | ||
// file at the top-level directory of this distribution and at | ||
// http://rust-lang.org/COPYRIGHT. | ||
// | ||
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or | ||
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license | ||
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your | ||
// option. This file may not be copied, modified, or distributed | ||
// except according to those terms. | ||
|
||
// FIXME: The assumes we're using the non-vector ABI, i.e. compiling | ||
// for a pre-z13 machine or using -mno-vx. | ||
|
||
use llvm::{Integer, Pointer, Float, Double, Struct, Array, Vector}; | ||
use abi::{FnType, ArgType}; | ||
use context::CrateContext; | ||
use type_::Type; | ||
|
||
use std::cmp; | ||
|
||
fn align_up_to(off: usize, a: usize) -> usize { | ||
return (off + a - 1) / a * a; | ||
} | ||
|
||
fn align(off: usize, ty: Type) -> usize { | ||
let a = ty_align(ty); | ||
return align_up_to(off, a); | ||
} | ||
|
||
fn ty_align(ty: Type) -> usize { | ||
match ty.kind() { | ||
Integer => ((ty.int_width() as usize) + 7) / 8, | ||
Pointer => 8, | ||
Float => 4, | ||
Double => 8, | ||
Struct => { | ||
if ty.is_packed() { | ||
1 | ||
} else { | ||
let str_tys = ty.field_types(); | ||
str_tys.iter().fold(1, |a, t| cmp::max(a, ty_align(*t))) | ||
} | ||
} | ||
Array => { | ||
let elt = ty.element_type(); | ||
ty_align(elt) | ||
} | ||
Vector => ty_size(ty), | ||
_ => bug!("ty_align: unhandled type") | ||
} | ||
} | ||
|
||
fn ty_size(ty: Type) -> usize { | ||
match ty.kind() { | ||
Integer => ((ty.int_width() as usize) + 7) / 8, | ||
Pointer => 8, | ||
Float => 4, | ||
Double => 8, | ||
Struct => { | ||
if ty.is_packed() { | ||
let str_tys = ty.field_types(); | ||
str_tys.iter().fold(0, |s, t| s + ty_size(*t)) | ||
} else { | ||
let str_tys = ty.field_types(); | ||
let size = str_tys.iter().fold(0, |s, t| align(s, *t) + ty_size(*t)); | ||
align(size, ty) | ||
} | ||
} | ||
Array => { | ||
let len = ty.array_length(); | ||
let elt = ty.element_type(); | ||
let eltsz = ty_size(elt); | ||
len * eltsz | ||
} | ||
Vector => { | ||
let len = ty.vector_length(); | ||
let elt = ty.element_type(); | ||
let eltsz = ty_size(elt); | ||
len * eltsz | ||
} | ||
_ => bug!("ty_size: unhandled type") | ||
} | ||
} | ||
|
||
fn classify_ret_ty(ccx: &CrateContext, ret: &mut ArgType) { | ||
if is_reg_ty(ret.ty) { | ||
ret.extend_integer_width_to(64); | ||
} else { | ||
ret.make_indirect(ccx); | ||
} | ||
} | ||
|
||
fn classify_arg_ty(ccx: &CrateContext, arg: &mut ArgType) { | ||
if arg.ty.kind() == Struct { | ||
fn is_single_fp_element(tys: &[Type]) -> bool { | ||
if tys.len() != 1 { | ||
return false; | ||
} | ||
match tys[0].kind() { | ||
Float | Double => true, | ||
Struct => is_single_fp_element(&tys[0].field_types()), | ||
_ => false | ||
} | ||
} | ||
|
||
if is_single_fp_element(&arg.ty.field_types()) { | ||
match ty_size(arg.ty) { | ||
4 => arg.cast = Some(Type::f32(ccx)), | ||
8 => arg.cast = Some(Type::f64(ccx)), | ||
_ => arg.make_indirect(ccx) | ||
} | ||
} else { | ||
match ty_size(arg.ty) { | ||
1 => arg.cast = Some(Type::i8(ccx)), | ||
2 => arg.cast = Some(Type::i16(ccx)), | ||
4 => arg.cast = Some(Type::i32(ccx)), | ||
8 => arg.cast = Some(Type::i64(ccx)), | ||
_ => arg.make_indirect(ccx) | ||
} | ||
} | ||
return; | ||
} | ||
|
||
if is_reg_ty(arg.ty) { | ||
arg.extend_integer_width_to(64); | ||
} else { | ||
arg.make_indirect(ccx); | ||
} | ||
} | ||
|
||
fn is_reg_ty(ty: Type) -> bool { | ||
match ty.kind() { | ||
Integer | ||
| Pointer | ||
| Float | ||
| Double => ty_size(ty) <= 8, | ||
_ => false | ||
} | ||
} | ||
|
||
pub fn compute_abi_info(ccx: &CrateContext, fty: &mut FnType) { | ||
if !fty.ret.is_ignore() { | ||
classify_ret_ty(ccx, &mut fty.ret); | ||
} | ||
|
||
for arg in &mut fty.args { | ||
if arg.is_ignore() { continue; } | ||
classify_arg_ty(ccx, arg); | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,6 +11,7 @@ | |
// ignore-android | ||
// ignore-arm | ||
// ignore-aarch64 | ||
// ignore-s390x | ||
|
||
#![feature(asm, rustc_attrs)] | ||
|
||
|
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we may need to add
-march=z10
to the list of CFLAGS because the gcc we'll be using in the buildbots (the Ubuntu 16.04 one) uses zEC12 as its default arch. Unless the z10 and newer are 100% compatible with the zEC12 instruction set. @uweigand, do you know if that's the case? (We use these CFLAGS to compile C dependencies of std like jemalloc)@alexcrichton we'll be using rustbuild to build std for this target. Does rustbuild pick up these CFLAGS or do they have to be set somewhere (e.g. in config.toml? or in the bootstrap crate?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah we'll need to modify gcc-rs to add this flag by default, or it can be added to
src/bootstrap/lib.rs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the last few generations of System Z processors are z10, z196, zEC12, and z13. In this order, each more recent processor is 100% upwards compatible with all earlier ones. Or to put it the other way, you can link together objects compiled for any of the processors, as long as you run the resulting binary on the most recent one. Therefore, I don't think it is particularly necessary to force the C components of std to be built for z10.
(The exception might be if you also run into problems with the valgrind tests since valgrind doesn't yet support all zEC12 instructions. That might indeed be a reason to use an older march level, until valgrind is fixed ...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, in the current state e.g. jemalloc will be compiled for the zEC12 (because that's gcc default arch/cpu level) and Rust code will be compiled for the z10 (because of the target definition) resulting in binaries that only work on zEC12 or newer (at least for std programs, which use/link-to jemalloc by default). Is that OK? I though that the intention of setting the target base cpu to z10 was to support processors as old as the z10?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intention was that the Rust upstream source code doesn't force use of a more recent processor on all users. In the context of a particular distribution, where the distro has chosen to require a particular minimum architecture level, then of course that minimum level also applies to Rust binaries (you cannot avoid this anyway, even if you build the C components of std with -march=z10, since it'll still link against libc.so itself, which was built with -march=zEC12 on Ubuntu).
However, if you build Rust on another distro, like RHEL 7 or SLES 12, both of which use a default arch level of z196, you don't want to artificially increase the required architecture level just because of the default level provided as part of the upstream Rust compiler sources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@uweigand oh one point that may be worth clarify I think @japaric means is that these flags are also used for the binary builds that we ourselves ship. For example for some platforms we disable a bunch of SSE-related things and for others we ratchet down the CPU to be a little older than it is by default. That way the binaries we ship end up being compatible with more systems.
If distros, though, use this same file to build their own binaries then they'll indeed be forced to use older cpus (like z10) by default as it's not easy to change the makefiles. This should be relatively ok, though because:
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, if you'd shipping binaries yourself, it makes sense to target an older CPU. If the flag to do so needs to be hard-coded in the sources because it's difficult to override, then I guess that's the way is has to be ... In the end, I agree that this shouldn't matter much performance-wise.
B.t.w. if you indeed build binaries to ship that are intended to support multiple distros, then the march level isn't the only problem. You'll also need to watch out for glibc symbol version issues; if you build on Ubuntu, it's possible that the resulting binary won't run on RHEL or SLES since those have much older glibc versions. The general recommendation would be to build binaries on the oldest distro you want to support (in which case also the march problem may be solved as well ...).