This commit implements stack probes on x86/x86_64 using the freshly landed
support upstream in LLVM. The purpose of stack probes here are to guarantee a
segfault on stack overflow rather than having a chance of running over the guard
page already present on all threads by accident.
At this time there's no support for any other architecture because LLVM itself
does not have support for other architectures.
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
Make wasm32 buildbot test LLVM backend
This adds the experimental targets option to configure so it can be used
by the builders and changes the wasm32 Dockerfile accordingly. Instead
of using LLVM from the emsdk, the builder's emscripten tools now uses
the Rust in-tree LLVM, since this is the one built with wasm support.
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
This is used in wasm32-experimental-emscripten to ensure that emscripten
links against the libc bitcode files produced by the wasm LLVM backend,
instead of using fastcomp.
Enable wasm LLVM backend
Enables compilation to WebAssembly with the LLVM backend using the target triple "wasm32-unknown-unknown". This is the beginning of my work on #38804.
**edit:** The new new target is now wasm32-experimental-emscripten instead of wasm32-unknown-unknown.
The new target is wasm32-experimental-emscripten. Adds a new
configuration option to opt in to building experimental LLVM backends
such as the WebAssembly backend. The target name was chosen to be
similar to the existing wasm32-unknown-emscripten target so that the
build and tests would work with minimal other code changes. When/if the
new target replaces the old target, simply renaming it should just work.
Without that flag, LLVM generates unaligned memory access instructions, which are not allowed on ARMv5.
For example, the 'hello world' example from `cargo --new` failed with:
```
$ ./hello
Hello, world!
thread 'main' panicked at 'assertion failed: end <= len', src/libcollections/vec.rs:1113
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
I traced this error back to the following assembler code in `BufWriter::flush_buf`:
```
6f44: e28d0018 add r0, sp, #24
[...]
6f54: e280b005 add fp, r0, #5
[...]
7018: e5cd001c strb r0, [sp, #28]
701c: e1a0082a lsr r0, sl, #16
7020: 03a01001 moveq r1, #1
7024: e5cb0002 strb r0, [fp, #2]
7028: e1cba0b0 strh sl, [fp]
```
Note that `fp` points to `sp + 29`, so the three `str*`-instructions should fill up a 32bit - value at `sp + 28`, which is later used as the value `n` in `Ok(n) => written += n`. This doesn't work on ARMv5 as the `strh` can't write to the unaligned contents of `fp`, so the upper bits of `n` won't get cleared, leading to the assertion failure in Vec::drain.
With `+strict-align`, the code works as expected.
This support is needed for bindgen to work well on 32-bit Windows, and
also enables people to begin experimenting with C++ FFI support on that
platform.
Fixes#42044.
Add -march=armv7-a parameter to armv7 android linker
Without this option, the linker fails to link any library that uses `std::future`. The error points some undefined references, like `std::__future_base::_Result_base`.
For example, it fails to link rustc because llvm 4.0 uses `std::future`.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735
Looks like the LinkerFlavor change introduced in #40018 accidentally uses GCC for the WebAssembly target, causing Rust to never actually pass the post link args to emscripten. This then causes the code to be compiled as asm.js instead of WebAssembly, because the Binaryen tools never run due to the missing linker argument.
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.
The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:
#![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
#![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]
This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:
* Mark themselves as entirely unstable via the `staged_api` feature and the
`#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
required if the crate relies on any other crates to compile (other than std).
* Update bootstrap to recognize the cputype 'sparcv9' (used on Solaris)
* Change to never use -fomit-frame-pointer on Solaris or for sparc
* Adds rust target sparcv9-sun-solaris
Fixes#39901
This might have performance implications. But do note that MSVC
disables FPO by default nowadays and it's use is limited in exception
heavy languages like C++.
Closes: #28218
Remove not(stage0) from deny(warnings)
Historically this was done to accommodate bugs in lints, but there hasn't been a
bug in a lint since this feature was added which the warnings affected. Let's
completely purge warnings from all our stages by denying warnings in all stages.
This will also assist in tracking down `stage0` code to be removed whenever
we're updating the bootstrap compiler.
Add socket timeout and ttl support in `sys::redox`
This adds support for `read_timeout`, `write_timeout`, and `ttl` on `TcpStream`, `TcpListener`, and `UdpSocket` in the `sys::redox` module.
The DNS lookup has been set to use a 5 second timeout by default.
Partial fix for #38489.
Fixes script name resolution for windows by invoking `emcc.bat` instead of `emcc`, etc.
Remaining issue:
```
Traceback (most recent call last):
File "C:\Program Files\Emscripten\emscripten\1.35.0\\emcc", line 1309, in <module>
final = shared.Building.llvm_opt(final, link_opts, DEFAULT_FINAL)
File "C:\Program Files\Emscripten\emscripten\1.35.0\tools\shared.py", line 1471, in llvm_opt
assert os.path.exists(target), 'Failed to run llvm optimizations: ' + output
AssertionError: Failed to run llvm optimizations:
```
Historically this was done to accommodate bugs in lints, but there hasn't been a
bug in a lint since this feature was added which the warnings affected. Let's
completely purge warnings from all our stages by denying warnings in all stages.
This will also assist in tracking down `stage0` code to be removed whenever
we're updating the bootstrap compiler.
Add a min_atomic_width target option, like max_atomic_width
Rationale: some ISAs, e.g. OR1K, do not have atomic instructions
for byte and halfword access, and at the same time do not have
a fixed endianness, which makes it unreasonable to implement these
through word-sized atomic accesses.
Rationale: some ISAs, e.g. OR1K, do not have atomic instructions
for byte and halfword access, and at the same time do not have
a fixed endianness, which makes it unreasonable to implement these
through word-sized atomic accesses.
Redox Cross Compilation
I will admit - there are things here that I wish I did not have to do. This completes the ability to create a cross compiler from the rust repository for `x86_64-unknown-redox`. I will document this PR with inline comments explaining some things.
[View this gist to see how a cross compiler is built](https://gist.github.com/jackpot51/6680ad973986e84d69c79854249f2b7e)
Prior discussion of a smaller change is here: https://github.com/rust-lang/rust/pull/38366
target spec: add an asm-args field to pass arguments to the external ..
assembler
The main use case is the (still out of tree) msp430 target. For that target we use an external assembler, `mps430-elf-gcc`, to produce object files from the assembly rustc/llvm outputs. The problem is that by default `msp430-elf-gcc` produces object files for the MSP430**X** ABI but we want to use produce objects using the MSP430 (note: no X) ABI. To do that we have to pass `-mcpu=msp430` to the assembler and that's what this flag is for.
r? @alexcrichton
cc @pftbest
We thought Google's ABI for arvm7 required neon, but it is
currently optional, perhaps because there is a significant
population of Tegra 2 devices still in use.
This turns off neon code generation outside #[target-feature]
blocks just like we do on armv7-unknown-linux-gnu, but unlike
most other armv7 targets. LLVM defaults to +neon for this target,
so an explicit disable is necessary.
See https://developer.android.com/ndk/guides/abis.html#v7a
for instruction set extension requirements.
Closes#38402.
Add i686-unknown-openbsd target.
It is a preliminary work. I still have some tests failing, but I have a working rustc binary which is able to rebuild itself.
an update of libc should be required too, but I dunno how to do it with vendor/ layout.
r? @alexcrichton
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.
There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.
Disable jemalloc on aarch64/powerpc
Sounds like jemalloc is broken on systems which differ in page size than the
host it was compiled on (unless an option was passed). This unfortunately
reduces the portability of binaries created and can often make Rust segfault by
default. For now let's patch over this by disabling jemalloc until we can figure
out a better solution.
Closes#36994Closes#37320
cc jemalloc/jemalloc#467
Support for aarch64 architecture on Fuchsia
This patch adds support for the aarch64-unknown-fuchsia target. Also
updates src/liblibc submodule to include required libc change.
Sounds like jemalloc is broken on systems which differ in page size than the
host it was compiled on (unless an option was passed). This unfortunately
reduces the portability of binaries created and can often make Rust segfault by
default. For now let's patch over this by disabling jemalloc until we can figure
out a better solution.
Closes#36994Closes#37320
cc jemalloc/jemalloc#467
check target abi support
This PR checks for each extern function / block whether the ABI / calling convention used is supported by the current target.
This was achieved by adding an `abi_blacklist` field to the target specifications, listing the calling conventions unsupported for that target.
rustc: Try again to disable NEON on armv7 linux
This is a follow-up to #35814 which apparently didn't disable it hard enough. It
looks like LLVM's default armv7 target enables NEON so we'd otherwise have to
pass `-neon`, but we're already enabling armv7 with `+v7` supposedly, so let's
try just telling LLVM that the armv7 target is arm and then enable features
selectively.
Closes#36913
This is a follow-up to #35814 which apparently didn't disable it hard enough. It
looks like LLVM's default armv7 target enables NEON so we'd otherwise have to
pass `-neon`, but we're already enabling armv7 with `+v7` supposedly, so let's
try just telling LLVM that the armv7 target is arm and then enable features
selectively.
Closes#36913
this commit adds 4 new target definitions to the compiler for easier
cross compilation to ARM Cortex-M devices.
- `thumbv6m-none-eabi`
- For the Cortex-M0, Cortex-M0+ and Cortex-M1
- This architecture doesn't have hardware support (instructions) for
atomics. Hence, the `Atomic*` structs are not available for this
target.
- `thumbv7m-none-eabi`
- For the Cortex-M3
- `thumbv7em-none-eabi`
- For the FPU-less variants of the Cortex-M4 and Cortex-M7
- On this target, all the floating point operations will be lowered
software routines (intrinsics)
- `thumbv7em-none-eabihf`
- For the variants of the Cortex-M4 and Cortex-M7 that do have a FPU.
- On this target, all the floating point operations will be lowered
to hardware instructions
No binary releases of standard crates, like `core`, are planned for
these targets because Cargo, in the future, will compile e.g. the `core`
crate on the fly as part of the `cargo build` process. In the meantime,
you'll have to compile the `core` crate yourself. [Xargo] is the easiest
way to do that as in handles the compilation of `core` automatically and
can be used just like Cargo: `xargo build --target thumbv6m-none-eabi`
is all that's needed.
[Xargo]: https://crates.io/crates/xargo
