about summary refs log tree commit diff
path: root/src/librustc_target
AgeCommit message (Collapse)AuthorLines
2019-10-29Rollup merge of #65832 - tlively:emscripten-exception-handling, r=alexcrichtonTyler Mandry-9/+2
Re-enable Emscripten's exception handling support Passes LLVM codegen and Emscripten link-time flags for exception handling if and only if the panic strategy is `unwind`. Sets the default panic strategy for Emscripten targets to `unwind`. Re-enables tests that depend on unwinding support for Emscripten, including `should_panic` tests. r? @alexcrichton
2019-10-29Rollup merge of #65809 - roblabla:eficall-abi, r=nagisaMazdak Farrokhzad-0/+9
Add new EFIAPI ABI Fixes #54527 Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI. Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
2019-10-29Rollup merge of #65294 - varkor:lint-inline-prototype, r=matthewjasperMazdak Farrokhzad-1/+1
Lint ignored `#[inline]` on function prototypes Fixes https://github.com/rust-lang/rust/issues/51280. - Adds a `unused_attribute` lint for `#[inline]` on function prototypes. - As a consequence, foreign items, impl items and trait items now have their attributes checked, which could cause some code to no longer compile (it was previously erroneously ignored).
2019-10-25Update bitflagsvarkor-1/+1
2019-10-25Re-enable Emscripten's exception handling supportThomas Lively-9/+2
Passes LLVM codegen and Emscripten link-time flags for exception handling if and only if the panic strategy is `unwind`. Sets the default panic strategy for Emscripten targets to `unwind`. Re-enables tests that depend on unwinding support for Emscripten, including `should_panic` tests.
2019-10-25Fix inverted check in EFIAPIroblabla-1/+1
2019-10-25Add new EFIAPI ABIroblabla-0/+9
Adds a new ABI for the EFIAPI calls. This ABI should reflect the latest version of the UEFI specification at the time of commit (UEFI spec 2.8, URL below). The specification says that for x86_64, we should follow the win64 ABI, while on all other supported platforms (ia32, itanium, arm, arm64 and risc-v), we should follow the C ABI. To simplify the implementation, we will simply follow the C ABI on all platforms except x86_64, even those technically unsupported by the UEFI specification. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
2019-10-22Merge branch 'master' into rusty-hermitStefan Lankes-4/+2
2019-10-21Remove many unnecessary trait derivations.Nicholas Nethercote-4/+2
2019-10-20Merge branch 'master' into rusty-hermitStefan Lankes-1/+15
2019-10-17Don't add `argc` and `argv` arguments to `main` on WASI.Dan Gohman-0/+10
Add a target setting to allow targets to specify whether the generated `main` function should be passed `argc` and `argv` arguments. Set it to false on wasm32-wasi, since WASI's `args::args()` calls into the WASI APIs itself. This will allow the WASI toolchain to avoid linking and running command-line argument initialization code when the arguments aren't actually needed.
2019-10-16Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-164/+105
- Compatible with Emscripten 1.38.46-upstream or later upstream. - Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the old incorrect wasm32 C call ABI with the correct one, preserving the old one as wasm32_bindgen_compat for wasm-bindgen compatibility. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
2019-10-10Check that we don't access nonexisting union fieldsOliver Scherer-1/+5
2019-10-06redesign of the interface to the unikernel HermitCoreStefan Lankes-16/+16
- the old interface between HermitCore and the Rust Standard Library based on a small C library (newlib) - remove this interface and call directly the unikernel - remove the dependency to the HermitCore linker - use rust-lld as linker
2019-10-04Add C ABI for wasm-bindgen compatThomas Lively-0/+30
2019-10-04Fix ABI, run and fix more tests, re-enable CI for PRsThomas Lively-10/+30
2019-10-04Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-164/+55
- Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the incorrect wasm32 C call ABI with the old asmjs version, which is correct for both wasm32 and JS. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Temporarily makes Emscripten targets use panic=abort by default because supporting unwinding will require an LLVM patch.
2019-09-29remove indexed_vec re-export from rustc_data_structurescsmoe-3/+3
2019-09-29Rollup merge of #64589 - andre-richter:aarch64_bare_metal, r=AmanieuMazdak Farrokhzad-2/+40
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/230 Closes: rust-embedded/wg#230
2019-09-28rustc: rely on c_variadic == true instead of CVarArgs in HIR/Ty fn signatures.Eduard-Mihai Burtescu-12/+4
2019-09-23Differentiate AArch64 bare-metal targets between hf and non-hf.Andre Richter-2/+40
Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal targets between versions with and without hardware 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/230 Closes: rust-embedded/wg#230
2019-09-13Auto merge of #64254 - aleksijuvani:fix-macos-sysroot, r=alexcrichtonbors-4/+44
Fix sysroot on macOS when cross-compiling and SDKROOT is set Fixes rust-lang/cargo#7283 Closes rust-lang/cargo#7284 r? @alexcrichton
2019-09-12Ignore linker env vars set for macOS on iOS targetsAleksi Juvani-3/+20
2019-09-12Remove env vars instead of setting them to an empty stringAleksi Juvani-9/+14
2019-09-11Auto merge of #64334 - jyao1:i686-master, r=joshtriplettbors-0/+99
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>
2019-09-10Set environment variables for linker instead of sysrootAleksi Juvani-81/+64
2019-09-10Add i686-unknown-uefi targetJiewen Yao-0/+99
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>
2019-09-08Fix cross-compilation to macOSAleksi Juvani-50/+62
2019-09-07Fix nitsAleksi Juvani-10/+10
2019-09-07Fix sysroot on macOS when cross-compiling and SDKROOT is setAleksi Juvani-44/+67
Fixes rust-lang/cargo#7283 Closes rust-lang/cargo#7284 r? @alexcrichton
2019-09-05rustc: Allow the cdylib crate type with wasm32-wasiAlex Crichton-0/+4
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
2019-08-31Add x86_64-linux-kernel targetAlex Gaynor-0/+60
This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures.
2019-08-16Rollup merge of #63604 - Wind-River:master, r=alexcrichtonMazdak Farrokhzad-198/+21
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
2019-08-16Rollup merge of #63595 - semarie:openbsd-sparc64, r=alexcrichtonMazdak Farrokhzad-0/+23
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.
2019-08-15add sparc64-unknown-openbsd targetSébastien Marie-0/+23
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.
2019-08-15Rollup merge of #63467 - ↵Mazdak Farrokhzad-3/+31
terhechte:support-ios-catalyst-macabi-target-triple, r=estebank 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](https://github.com/apple/swift-llvm/commit/3f1fd4f46a8e82cee6fffb284ee46daf8ddf66ae) 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)
2019-08-15Rollup merge of #63165 - xen0n:mips64-musl-targets, r=alexcrichtonMazdak Farrokhzad-0/+52
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*
2019-08-15Rollup merge of #63155 - mfkl:uwp-msvc, r=alexcrichtonMazdak Farrokhzad-0/+105
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 https://github.com/rust-lang/rust/commit/5e6619edd1a3b5c3f85438166d4d32af49f800fd 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.
2019-08-14Handle cfg(bootstrap) throughoutMark Rousskov-13/+6
2019-08-131. support crt-staticBaoshan Pang-198/+21
2. change armv7_wrs_vxworks to armv7_wrs_vxworks_eabihf. 3. use wr-** instead of vx-** 4. set PIE to false 5. code cleanup
2019-08-11Add initial files for iOS catalyst / macabi supportBenedikt Terhechte-3/+31
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.
2019-08-10rustc_target: add n64 musl targets for MIPS64 archesWang Xuerui-0/+52
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.
2019-08-08move store lib probing code to librustc_codegen_ssaMartin Finkel-40/+0
2019-08-07Auto merge of #60547 - redox-os:redox-unix, r=alexcrichtonbors-7/+31
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
2019-08-07Auto merge of #63152 - estebank:big-array, r=oli-obkbors-0/+4
Always error on `SizeOverflow` during mir evaluation Fix #55878, fix #25116. r? @oli-obk
2019-08-06redox: convert to target_family unixJeremy Soller-7/+31
2019-08-05review feedback: find lib root path from registryMartin Finkel-9/+19
2019-08-04review comments: clean upEsteban Küber-1/+1
2019-08-03Simplify change to layout_ofEsteban Küber-1/+3
2019-08-03Point to local place span on "type too big" errorEsteban Küber-0/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-12 03:39:39 +0000