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
