LLVM 9 is adding support for a "pic" relocation model for wasm code,
which is quite different than the current model. In order to preserve
the mode of compilation that we have today default to "static" to ensure
that we don't accidentally start creating experimental relocatable
binaries.
rustc_target: factor out common fields of non-Single Variants.
@tmandry and I were discussing ways to generalize the current variants/discriminant layout to allow more fields in the "`enum`" (or another multi-variant types, such as potentially generator state, in the future), shared by all variants, than just the tag/niche discriminant.
This refactor should make it easier to extend multi-variant layouts, as nothing is duplicating anymore between "tagged enums" and "niche-filling enums".
r? @oli-obk
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
[LINK]:
[wasmtime]:
This commit adds support code for using `clang` directly to link the
wasm32-unknown-unknown target. Currently the target is only really
configured to link with LLD directly, but this ensures that `clang` can
be configured as well.
While not immediately useful in the near term it's likely that more
wasm32 targets will pop up over time with Clang's new native support for
WebAssembly in the 8.0.0 release. Getting support into rustc early
should make it easier to experiment with these targets and try out
various changes here and there.
Default to integrated `rust-lld` linker for UEFI targets
The `x86_64-unknown-uefi` target was added in https://github.com/rust-lang/rust/pull/56769 with the linker defaulting to `lld-link`. This means that a system linker with that name is required for linking.
I think defaulting to `rust-lld`, which is shipped with Rust, is a better default for the following reasons:
- Most systems don't have `lld-link` installed, so it forces users to install it first.
- The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu `apt install lld` leads to an executable named `lld-link-6.0`.
- We already default to `rust-lld` for [many targets](https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=rust-lld&type=), including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like `x86_64-unknown-uefi` is the [only target](https://github.com/rust-lang/rust/search?q=lld-link&unscoped_q=lld-link) that uses `lld-link`.)
cc @dvdhrm who added the target and @kkk669 who [proposed to use `rust-lld`](https://github.com/rust-lang/rust/pull/56769#issuecomment-461119648).
MIPS: add r6 support
MIPS r6 is quite different with the previous version.
It use some new target triples:
mipsisa32r6-unknown-linux-gnu
mipsisa32r6el-unknown-linux-gnu
mipsisa64r6-unknown-linux-gnuabi64
mipsisa64r6el-unknown-linux-gnuabi64
This patch has been tested with Debian Port for mips64r6el,
and the support of these triples also is included in llvm:
https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
MIPS r6 is quite different with the previous version.
It use some new target triples:
mipsisa32r6-unknown-linux-gnu
mipsisa32r6el-unknown-linux-gnu
mipsisa64r6-unknown-linux-gnuabi64
mipsisa64r6el-unknown-linux-gnuabi64
This patch has been tested with Debian Port for mips64r6el,
and the support of these triples also is included in llvm:
https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
Function signatures with the `variadic` member set are actually
C-variadic functions. Make this a little more explicit by renaming the
`variadic` boolean value, `c_variadic`.
Before this commit, if the builtin target was found, but an error
happened when instantiating it (e.g. validating the target
specification file failed, etc.), then we ignored those errors
and proceeded to try to find a `target_triple.json` file, and if
that failed, reported that as an error.
With this commit, if rustc is supposed to provide the builtin target,
and something fails while instantiating it, that error will
get properly propagated.
This clarifies why FP-units are disabled on UEFI targets, as well as
why we must opt into the NXCOMPAT feature.
I did find some time to investigate why GRUB and friends disable FP on
UEFI. The specification explicitly allows using MMX/SSE/AVX, but as it
turns out it does not mandate enabling the instruction sets explicitly.
Hence, any use of these instructions will trigger CPU exceptions,
unless an application explicitly enables them (which is not an option,
as these are global flags that better be controlled by the
kernel/firmware).
Furthermore, UEFI systems are allowed to mark any non-code page as
non-executable. Hence, we must make sure to never place code on the
stack or heap. So we better pass /NXCOMPAT to the linker for it to
complain if it ever places code in non-code pages.
Lastly, this fixes some typos in related comments.
targets: aarch64-unknown-none: Add +strict-align
On AArch64, an unaligned access causes a synchronous exception. In the current
state of the target, the compiler might generate unaligned accesses, see
https://github.com/rust-embedded/rust-raspi3-tutorial/issues/10.
Since this is a bare-metal target, it is possible that there is no exception
handling in place (yet) to recover from this case, causing a binary to just
silently fail.
Add `+strict-align` to avoid this case.
On AArch64, an unaligned access causes a synchronous exception. In the current
state of the target, the compiler might generate unaligned accesses, see
https://github.com/rust-embedded/rust-raspi3-tutorial/issues/10.
Since this is a bare-metal target, it is possible that there is no exception
handling in place (yet) to recover from this case, causing a binary to just
silently fail.
Add `+strict-align` to avoid this case.
"trampolines", or "aliases (the default)) to allow targets to opt out of
the MergeFunctions LLVM pass. Also add a corresponding -Z option with
the same name and values.
This works around: https://github.com/rust-lang/rust/issues/57356
Motivation:
Basically, the problem is that the MergeFunctions pass, which rustc
currently enables by default at -O2 and -O3, and `extern "ptx-kernel"`
functions (specific to the NVPTX target) are currently not compatible
with each other. If the MergeFunctions pass is allowed to run, rustc can
generate invalid PTX assembly (i.e. a PTX file that is not accepted by
the native PTX assembler ptxas). Therefore we would like a way to opt
out of the MergeFunctions pass, which is what our target option does.
Related work:
The current behavior of rustc is to enable MergeFunctions at -O2 and -O3,
and also to enable the use of function aliases within MergeFunctions.
MergeFunctions both with and without function aliases is incompatible with
the NVPTX target.
clang's "solution" is to have a "-fmerge-functions" flag that opts in to
the MergeFunctions pass, but it is not enabled by default.
Adding unwinding support for x86_64_fortanix_unknown_sgx target.
Unwinding support is provided by our port of LLVM's libunwind which is available from https://github.com/fortanix/libunwind/tree/release_50.
libunwind requires support for rwlock and printing to stderr, which is only provided by `std` for this target. This poses two problems: 1) how to expose the `std` functionality to C and 2) dependency inversion.
### Exposing `std`
For exposing the functionality we chose to expose the following symbols:
* __rust_rwlock_rdlock
* __rust_rwlock_wrlock
* __rust_rwlock_unlock
* __rust_print_err
* __rust_abort
Also, the following are needed from `alloc`:
* __rust_alloc
* __rust_dealloc
#### Rust RWLock in C
In `libunwind`, RWLock is initialized as a templated static variable:
```c
pthread_rwlock_t DwarfFDECache<A>::_lock = PTHREAD_RWLOCK_INITIALIZER;
```
I don't know of a good way to use the Rust sys::rwlock::RWLock type and initializer there. We could have a static global variable in Rust, but that doesn't work with the templating. The variable needs to be initialized statically, since this target doesn't support the .init section. Currently, I just used a byte array and standard C array initialization. The mapping between this C type and the Rust type needs to be manually maintained. There is a compile-time check and a unit test to make sure the Rust versions of these C definitions match the actual Rust type. If any reviewer knows of a better solution, please do tell.
### Dependency inversion issue
`std` depends on `panic_unwind` which depends on `libunwind`, and `libunwind` depends on `std`. This is not normally supported by Rust's linking system. Therefore we use raw C exports from `std` *and* `libunwind.a` is linked last in the target `post_link_objects` instead of being built as part of the Rust `libunwind`. Currently, all C exports are defined in `src/libstd/sys/sgx/rwlock.rs` to overcome LTO issues. Only the `__rust_rwlock_*` definitions *need* to live there for privacy reasons. Once again, if any reviewer knows of a better solution, please do tell.
r? @alexcrichton
Add targets thumbv7neon-linux-androideabi and thumbv7neon-unknown-linux-gnueabihf
These two targets enable both thumb-mode and NEON for ARMv7 CPUs.
This another attempt at #49902, which cannot be reopened. Between that PR and this one, some subrepos with C code whose build systems were failing went away.
Provide -isysroot with sdkroot for ios builds
Necessary for the new XCode?
Absolutely positively definitely untested… although I did
```
cargo rustc -- -Clink-arg=-isysroot -Clink-arg=$sdk_root
```
and stuff did compile for once.
Always set the RDRAND and RDSEED features on SGX
Not sure if this is 100% correct.
This [Intel article](https://software.intel.com/en-us/articles/intel-software-guard-extensions-tutorial-part-5-enclave-development) goes in great depth regarding using (untrusted) CPUID to see whether RDRAND/RDSEED is supported, and explains what happens to the enclave if the CPUID result is faked.
I'd say that an implementation of SGX that doesn't make RDRAND available to the enclave is so severely limited/broken that it's ok if you get #UD in that case. The case is less clear for RDSEED, but it so far every processor released by Intel with SGX support also has RDSEED (including Gemini Lake).
cc @briansmith
Add x86_64-unknown-uefi target
This adds a new rustc target-configuration called 'x86_64-unknown_uefi'.
Furthermore, it adds a UEFI base-configuration to be used with other
targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...).
UEFI systems provide a very basic operating-system environment, meant
to unify how systems are booted. It is tailored for simplicity and fast
setup, as it is only meant to bootstrap other systems. For instance, it
copies most of the ABI from Microsoft Windows, rather than inventing
anything on its own. Furthermore, any complex CPU features are
disabled. Only one CPU is allowed to be up, no interrupts other than
the timer-interrupt are allowed, no process-separation is performed,
page-tables are identity-mapped, ...
Nevertheless, UEFI has an application model. Its main purpose is to
allow operating-system vendors to write small UEFI applications that
load their kernel and terminate the UEFI system. However, many other
UEFI applications have emerged in the past, including network-boot,
debug-consoles, and more.
This UEFI target allows to compile rust code natively as UEFI
applications. No standard library support is added, but libcore can be
used out-of-the-box if a panic-handler is provided. Furthermore,
liballoc works as well, if a `GlobalAlloc` handler is provided. Both
have been tested with this target-configuration.
Note that full libstd support is unlikely to happen. While UEFI does
have standardized interfaces for networking and alike, none of these
are mandatory and they are unlikely to be shipped in common consumer
firmwares. Furthermore, several features like process-separation are
not available (or only in very limited fashion). Those parts of libstd
would have to be masked.
