This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete. This includes:
- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
(only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x
Caveats:
- Resets base cpu to "z10" to bring support in sync with the default
behaviour of other compilers on the platforms. (Usually, upstream
supports all older processors; a distribution build may then chose
to require a more recent base version.) (Also, using zEC12 causes
failures in the valgrind tests since valgrind doesn't fully support
this CPU yet.)
- z13 vector ABI is not yet supported. To ensure compatible code
generation, the -vector feature is passed to LLVM. Note that this
means that even when compiling for z13, no vector instructions
will be used. In the future, support for the vector ABI should be
added (this will require common code support for different ABIs
that need different data_layout strings on the same platform).
- Two test cases are (temporarily) ignored on s390x to allow passing
the test suite. The underlying issues still need to be fixed:
* debuginfo/simd.rs fails because of incorrect debug information.
This seems to be a LLVM bug (also seen with C code).
* run-pass/union/union-basic.rs simply seems to be incorrect for
all big-endian platforms.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
add mips64-gnu and mips64el-gnu targets
With this commit one can build no_core (and probably no_std as well)
Rust programs for these targets. It's not yet possible to cross compile
std for these targets because rust-lang/libc doesn't know about the
mips64 architecture.
These targets have been tested by cross compiling the "smallest hello"
program (see code below) and then running it under QEMU.
``` rust
extern {
fn puts(_: *const u8);
}
fn start(_: isize, _: *const *const u8) -> isize {
unsafe {
let msg = b"Hello, world!\0";
puts(msg as *const _ as *const u8);
}
0
}
trait Copy {}
trait Sized {}
```
cc #36015
r? @alexcrichton
cc @brson
The cabi stuff is likely wrong. I just copied cabi_mips source and changed some `4`s to `8`s and `32`s to `64`s. It was enough to get libc's `puts` to work but I'd like someone familiar with this module to check it.
DoubleEndedIterator for Args
This PR implements the DoubleEndedIterator trait for the `std::env::Args[Os]` structure, as well
as the internal implementations.
It is primarily motivated by me, as I happened to implement a simple `reversor` program many times
now, which so far had to use code like this:
```Rust
for arg in std::env::args().skip(1).collect::<Vec<_>>().iter().rev() {}
```
... even though I would have loved to do this instead:
```Rust
for arg in std::env::args().skip(1).rev() {}
```
The latter is more natural, and I did not find a reason for not implementing it.
After all, on every system, the number of arguments passed to the program are known
at runtime.
To my mind, it follows KISS, and does not try to be smart at all. Also, there are no unit-tests,
primarily as I did not find any existing tests for the `Args` struct either.
The windows implementation is basically a copy-pasted variant of the `next()` method implementation,
and I could imagine sharing most of the code instead. Actually I would be happy if the reviewer would
ask for it.
The number of arguments given to a process is always known, which
makes implementing DoubleEndedIterator possible.
That way, the Iterator::rev() method becomes usable, among others.
Signed-off-by: Sebastian Thiel <byronimo@gmail.com>
Tidy for DoubleEndedIterator
I chose to not create a new feature for it, even though
technically, this makes me lie about the original availability
of the implementation.
Verify with @alexchrichton
Setup feature flag for new std::env::Args iterators
Add test for Args reverse iterator
It's somewhat depending on the input of the test program,
but made in such a way that should be somewhat flexible to changes
to the way it is called.
Deduplicate windows ArgsOS code for DEI
DEI = DoubleEndedIterator
Move env::args().rev() test to run-pass
It must be controlling it's arguments for full isolation.
Remove superfluous feature name
Assert all arguments returned by env::args().rev()
Let's be very sure it works as we expect, why take chances.
Fix rval of os_string_from_ptr
A trait cannot be returned, but only the corresponding object.
Deref pointers to actually operate on the argument
Put unsafe to correct location
Add some warnings to std::env::current_exe
/cc #21889 @rust-lang/libs @semarie
I started writing this up. I'm not sure if we want to go into other things and in what depth; we don't currently have a lot of security-specific documentation to model after.
Thoughts?
Backtraces, and the compilation of libbacktrace for asmjs, are disabled.
This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets*
in the configure file.
It disables stack protection.
This pull request adds support for [Illumos](http://illumos.org/)-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on #28589 by @potatosalad, and also closes#21000, #25845, and #25846.
Required changes in libc are already merged: https://github.com/rust-lang-nursery/libc/pull/138
Here's a snapshot required to build a stage0 compiler:
https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz
It passes all checks from `make check`.
There are some changes I'm not quite sure about, e.g. macro usage in `src/libstd/num/f64.rs` and `DirEntry` structure in `src/libstd/sys/unix/fs.rs`, so any comments on how to rewrite it better would be greatly appreciated.
Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409
Thanks!
r? @brson
Currently the `mipsel-unknown-linux-gnu` target doesn't actually set the
`target_arch` value to `mipsel` but it rather uses `mips`. Alternatively the
`powerpc64le` target does indeed set the `target_arch` as `powerpc64le`,
causing a bit of inconsistency between theset two.
As these are just the same instance of one instruction set, let's use
`target_endian` to switch between them and only set the `target_arch` as one
value. This should cut down on the number of `#[cfg]` annotations necessary and
all around be a little more ergonomic.
