Differentiate AArch64 bare-metal targets between hf and non-hf.
CC @parched, kindly request you to review.
~~Note: This change breaks code that uses the target `aarch64-unknown-none` for the sake of clearer naming as discussed in the links posted below. A search on github reveals that code using `aarch64-unknown-none` is almost exclusively forked from our embedded WG's OS tutorials repo at https://github.com/rust-embedded/rust-raspi3-OS-tutorials, for which the target was originally created.~~
~~I will adapt this repo to the new target name asap once this PR would go upstream. The minor annoyance for the forks to break temporarily should be acceptable for the sake of introducing a better differentiation now before it is too late.
Also, the break would only happen upon updating the toolchain, giving the user a good hint at what has happened.~~
---------- Patch commit message:
Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal
targets between versions with and without floating point enabled.
This streamlines the target naming with other existing ARM targets and provides
the user clear indication if he is getting float or non-float for his bare-metal
target.
[1] https://github.com/rust-lang/rust/pull/60135#issuecomment-485851356
[2] https://github.com/rust-embedded/wg/issues/230Closes: rust-embedded/wg#230
Add i686-unknown-uefi target
This adds a new rustc target-configuration called 'i686-unknown_uefi'.
This is similar to existing x86_64-unknown_uefi target.
The i686-unknown-uefi target can be used to build Intel Architecture
32bit UEFI application. The ABI defined in UEFI environment (aka IA32)
is similar to cdecl.
We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid
the intrinsics generated by LLVM. The detail of root-cause and solution
analysis is added as comment in the code.
For x86_64-unknown-uefi, we cannot use -gnu, because the ABI between
MSVC and GNU is totally different, and UEFI chooses ABI similar to MSVC.
For i686-unknown-uefi, the UEFI chooses cdecl ABI, which is same as
MSVC and GNU. According to LLVM code, the only differences between MSVC
and GNU are fmodf(f32), longjmp() and TLS, which have no impact to UEFI.
As such, using i686-unknown-uefi-gnu is the simplest way to pass the build.
Adding the undefined symbols, such as _aulldiv() to rust compiler-builtins
is out of scope. But it may be considered later.
The scope of this patch is limited to support target-configuration.
No standard library support is added in this patch. Such work can be
done in future enhancement.
Cc: Josh Triplett <josh.triplett@intel.com>
Reviewed-by: Josh Triplett <josh.triplett@intel.com>
This adds a new rustc target-configuration called 'i686-unknown_uefi'.
This is similar to existing x86_64-unknown_uefi target.
The i686-unknown-uefi target can be used to build Intel Architecture
32bit UEFI application. The ABI defined in UEFI environment (aka IA32)
is similar to cdecl.
We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid
the intrinsics generated by LLVM. The detail of root-cause and solution
analysis is added as comment in the code.
For x86_64-unknown-uefi, we cannot use -gnu, because the ABI between
MSVC and GNU is totally different, and UEFI chooses ABI similar to MSVC.
For i686-unknown-uefi, the UEFI chooses cdecl ABI, which is same as
MSVC and GNU. According to LLVM code, the only differences between MSVC
and GNU are fmodf(f32), longjmp() and TLS, which have no impact to UEFI.
As such, using i686-unknown-uefi-gnu is the simplest way to pass the build.
Adding the undefined symbols, such as _aulldiv() to rust compiler-builtins
is out of scope. But it may be considered later.
The scope of this patch is limited to support target-configuration.
No standard library support is added in this patch. Such work can be
done in future enhancement.
Cc: Josh Triplett <josh.triplett@intel.com>
Reviewed-by: Josh Triplett <josh.triplett@intel.com>
The wasm32-wasi target respects configuration around `crt-static` in
general, but is defaulted to being static. This interacted badly with
code which validated the `cdylib` crate type for `wasm32-wasi`,
erroneously saying that the `cdylib` crate type wasn't supported on
`wasm32-wasi` by default. This commit sets the appropriate flag in
`wasm32_wasi`'s target specification to indicate that the `cdylib` crate
type is supported regardless of `crt-static`
Closes#64187
Some update for vxWorks
1. support crt-static
2. change armv7_wrs_vxworks to armv7_wrs_vxworks_eabihf.
3. change vx-cxx to wr-c++, vx-ar to wr-ar and vx-run to wr-run.
4. code cleanup
r? @alexcrichton
add sparc64-unknown-openbsd target
on OpenBSD, some architectures relies on libc++ (from LLVM) and some
others on libestdc++ (particular version of libstdc++ from GCC).
sparc64-unknown-openbsd needs libestdc++ and libgcc (as x86_64 some
years ago). Reintroduce the support of them for openbsd, only for
sparc64 arch. Some others architectures on OpenBSD could use them too.
on OpenBSD, some architectures relies on libc++ (from LLVM) and some
others on libestdc++ (particular version of libstdc++ from GCC).
sparc64-unknown-openbsd needs libestdc++ and libgcc (as x86_64 some
years ago). Reintroduce the support of them for openbsd, only for
sparc64 arch. Some others architectures on OpenBSD could use them too.
Add Catalyst (iOS apps running on macOS) target
This is a first attempt of adding support for the new [Apple Catalyst](https://developer.apple.com/ipad-apps-for-mac/) target (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS:
- iOS: ARM cpu, iOS SDK, linked agains the iOS ABI
- Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI
Apple Catalyst will add an additional target:
- Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI.
Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15.
I've collected additional information via links in the open question sections below. This is way out of my comfort zone so please excuse whatever errors I may have made.
# Open Questions:
## Clang Version
It seems to me that `macabi` has not been merged into `clang` yet, I don't know whether that is a requirement rustc to compile, or if it is sufficient if the Clang that is used on a developers system is the correct one supporting macabi (that comes with current Xcode)
## Hardcoded iOS version
`swift-llvm` actually used [x86_64-apple-ios13.0-macabi](3f1fd4f46a) as the target triple which hard-codes the current iOS version. A post on stackoverflow [points out that `MIN_IOS_VERSION` and `MIN_OSX_VERSION` should be used when compiling C code for clang (`-target x86_64-apple-ios${MIN_IOS_VERSION}-macabi`)](https://stackoverflow.com/questions/56487645/how-to-compile-a-3rd-party-library-to-be-used-with-uikit-for-mac-catalyst). However, I wasn't entirely sure how to do that in this PR. Pointers welcome.
## Data Layout
I'm probably using the wrong data-layout. I don't know whether it should be the macOS version or the iOS version. This is probably easier to answer for somebody who understands these things much better than me. I just copied the iOS Simulator X86_64 version as it seems to be (based on what I understand) that Catalyst is just the simulator target build against a different SDK.
# Current State
1. I got it to compile
2. I could successfully compile a `macabi` `libcore` via `cargo build --target x86_64-apple-ios-macabi`
I'm not sure what needs to be done next. Supposedly I need to compile everything into a toolchain somehow that I can then test via `rustup` to make sure that a binary compiled against the toolchain also works with Catalyst. [I read this article, but I'm still lost](https://www.reddit.com/r/rust/comments/5ag60z/how_do_i_bootstrap_rust_to_crosscompile_for_a_new/d9gicr2/) and would love pointers what to do next here.
# Additional Information
- [Commit adding Catalyst support to the Swift Clang Fork](https://github.com/CocoaPods/CocoaPods/issues/8877)
- [Compiling C to Catalyst Discussion](https://github.com/CocoaPods/CocoaPods/issues/8877)
- [CocoaPods Discussion on Adding Catalyst support](https://github.com/CocoaPods/CocoaPods/issues/8877)
Add builtin targets for mips64(el)-unknown-linux-muslabi64
This is prerequisite for rust-lang/libc#1449.
Tested locally to produce working static and dynamic binaries, ~~but CI config is untested for now~~ CI is to be added in a follow-up PR.
*edit: dynamic binaries also confirmed working!*
*edit 2: changed triples to include ABI, and removed stray `crt_static_default = false` declarations to be consistent with other musl targets*
Add UWP MSVC targets
Hi,
- The README URI change is the correct one for VS2019 community edition, which I suspect most people would use. Doesn't _need_ to be merged though.
- This 5e6619edd1 fixes the UWP build (msvc or not, doesn't matter). I suspect it broke with recent changes unnoticed because no CI.
- Store lib location is found through the VCToolsInstallDir env variable. The end of the path is currently for the VS2019 store lib locations only.
- I could not test the aarch64_uwp_windows_msvc target because the rust build script does not currently support arm64 msvc AFAIU.
This is a first attempt of adding support for the new Apple Catalyst ABI (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS:
- iOS: ARM cpu, iOS SDK, linked agains the iOS ABI
- Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI
Apple Catalyst will add an additional target:
- Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI.
Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15.
This commits adds the files for this new target triple.
Hard-float (unlike mips32 musl targets but consistent with any other
musl target), MIPS64r2, n64 ABI.
The triples are renamed to carry the `abi64` ABI suffix found on all
other MIPS64 targets, for consistency and forward compatibility, should
Rust gain support for the n32 ABI one day.
redox: convert to target_family unix
This is the second step to supporting rust-lang/rust#60139.
In order to have a smooth transition, there will need to be a change made in liblibc at the same time, switching Redox over to the unix target family. See https://github.com/rust-lang/libc/pull/1332
Added support for armv7-unknown-linux-gnueabi/musleabi
Fixes#63101
Some things that are not done and I hope someone can help me with:
* During the ci build of `armv7-unknown-linux-gnueabi` `openssl` must be built (to build cargo) but `openssl` does not yet support this target. This feels slightly like a chicken-and-egg problem, any feedback is welcome.
* Should I add any tests for any of these targets?
rustc: Update wasm32 support for LLVM 9
This commit brings in a number of minor updates for rustc's support for
the wasm target which has changed in the LLVM 9 update. Notable updates
include:
* The compiler now no longer manually inserts the `producers` section,
instead relying on LLVM to do so. LLVM uses the `llvm.ident` metadata
for the `processed-by` directive (which is now emitted on the wasm
target in this PR) and it uses debuginfo to figure out what `language`
to put in the `producers` section.
* Threaded WebAssembly code now requires different flags to be passed
with LLD. In LLD we now pass:
* `--shared-memory` - required since objects are compiled with
atomics. This also means that the generated memory will be marked as
`shared`.
* `--max-memory=1GB` - required with the `--shared-memory` argument
since shared memories in WebAssembly must have a maximum size. The
1GB number is intended to be a conservative estimate for rustc, but
it should be overridable with `-C link-arg` if necessary.
* `--passive-segments` - this has become the default for multithreaded
memory, but when compiling a threaded module all data segments need
to be marked as passive to ensure they don't re-initialize memory
for each thread. This will also cause LLD to emit a synthetic
function to initialize memory which users will have to arrange to
call.
* The `__heap_base` and `__data_end` globals are explicitly exported
since they're now hidden by default due to the `--export` flags we
pass to LLD.
Disable d32 on armv6 hf targets
We already do this on armv7 targets. It seems that this now gets enabled by default if '+vfp2` is specified, so disable it explicitly.
Hopefully fixes#62841.
r? @alexcrichton
rustc: precompute the largest Niche and store it in LayoutDetails.
Since we only ever can use at most one niche, it makes sense to just store that in the layout, for the simplest caching (especially as it's almost trivial to compute).
There might be a speedup from this, but even if it's marginal now, the caching would be a more significant benefit for future optimization attempts.
This commit moves `thread_local!` on WebAssembly targets to using the
`#[thread_local]` attribute in LLVM. This was recently implemented
upstream and is [in the process of being documented][dox]. This change
only takes affect if modules are compiled with `+atomics` which is
currently unstable and a pretty esoteric method of compiling wasm
artifacts.
This "new power" of the wasm toolchain means that the old
`wasm-bindgen-threads` feature of the standard library can be removed
since it should now be possible to create a fully functioning threaded
wasm module without intrusively dealing with libstd symbols or
intrinsics. Yay!
[dox]: https://github.com/WebAssembly/tool-conventions/pull/116
