The SystemZ `LALR` instruction provides PC-relative addressing for
globals, but only to *even* addresses, so other compilers make sure that
such globals are always 2-byte aligned. In Clang, this is modeled with
`TargetInfo::MinGlobalAlign`, and `TargetOptions::min_global_align` now
serves the same purpose for rustc.
In Clang, the only targets that set this are SystemZ, Lanai, and NVPTX,
and the latter two don't have targets in rust master.
haiku/librustc_back: Remove incorrect no_integrated_as
* Makes rust bootstrap incorrectly search for xxx.s vs xxx.0.s
* Not needed or incorrect fix for another issue.
L4Re Target: Add the needed Libraries and locate them
Add the libraries and objects that have to be linked to a get working L4Re Binary using pre- and post-link-args. Additionaly some ld commands had to be passed.
* L4Re libraries and objects will be located by an environment variable.
* gcc libraries and objects will be located using a gcc call.
GCC is mandatory for this target, that might need documentation somewhere. As soon as something mandatory cannot be found, the compiler will panic. This is intended, because the functions involved don't allow the usage of a Result type. libgcc_eh is now passed using `-l` and crtbeginT.o and crtend.o are now located using `gcc -print-filename`.
Most UNIX-like platforms do not allow shared libraries to statically
link their own libc, as libc expects to have consistent process-global
state. On those platforms, when we do not have a shared libc available,
we must not attempt to link dylibs or cdylibs. On Windows, however, it
is expected to statically link the CRT into dynamic libraries.
This feature is only relevant for targets that support both fully-static
and fully-dynamic linkage, such as musl on Linux.
This feature allows targets to opt in to full support of the crt-static
feature. Currently, crt-static is allowed on all targets, even those
that really can't or really shouldn't support it. This works because it
is very loose in the specification of its effects. Changing the behavior
of crt-static to be more strict in how it chooses libraries and links
executables would likely cause compilation to fail on these platforms.
To avoid breaking existing uses of crt-static, whitelist targets that
support the new, stricter behavior. For all other targets, this changes
crt-static from being "mostly a no-op" to "explicitly a no-op".
Add the libraries and objects that have to be linked to a get working L4Re
Binary using pre- and post-link-args. Additionaly some ld commands had to
be passed.
* L4Re libraries and objects will be located by an environment variable.
* gcc libraries and objects will be located using a gcc call.
GCC is mandatory for this target, that might need documentation somewhere.
As soon as something mandatory cannot be found, the compiler will panic.
This is intended, because the functions involved don't allow the usage of
a Result type. libgcc_eh is now passed using `-l` and crtbeginT.o and
crtend.o are now located using `gcc -print-filename`.
Co-authored-by: TobiasSchaffner <tobiasschaffner@outlook.com>
This commit adds some "boilerplate" build scripts to librustc/libsyntax crates
to declare dependencies on various environment variables that are configured
throughout the build. Cargo recently gained the ability to depend on environment
variables in build scripts which can help trigger recompilation of a crate.
This should fix weird bugs where after you make a commit or a few days later
you'll get weird "not built with the same compiler" errors hopefully.
Tells emcc to enable assertions and debugging information for
wasm32-experimental-emscripten. This makes the codegen issues caused by
LLVM bug 33824 manifest more frequently at runtime and improves the wasm
debugging experience.
On at least RHEL6 there is a segfault caused by the older ld.so version
when BIND_NOW is used, so use partial RELRO by default on ppc64
architectures for now.
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
add a built-in MSP430 target
the MSP430 backend has been enabled for a while but no target was added to rustc
to encourage out of tree experimentation.
We believe the out of tree (custom) target has been iterated long enough and is
stable enough for inclusion in the compiler. Kudos to @pftbest and @awygle for
fixing several LLVM / codegen bugs this target had!
The target name chosen is a slight variation of the triple gcc uses, which is
simply `msp430-elf`. We picked `msp430-none-elf` to leave room for custom
targets that target some embedded OS running on MSP430 devices. (cf. the
custom `thumbv7m-tockos-eabi` target TockOS uses vs the built-in
`thumbv7m-none-eabi`).
There's one expected change in the specification of the proposed target: the
`asm_args` and `no_integrated_as` fields will change to their default values.
Once the LLVM backend gains the ability to directly produce MSP430 object files
we can stop depending on `msp430-elf-gcc` for producing object files; when that
occurs the `asm` related fields will change. This change won't break existing
user code.
r? @alexcrichton
cc @brson
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
