about summary refs log tree commit diff
path: root/src/librustc_target
AgeCommit message (Collapse)AuthorLines
2019-05-04Move pointee_info_at to TyLayoutMethods.Daan de Graaf-0/+27
The original implementation is still present at librustc_codegen_llvm/abi.rs, should be removed later to prevent code duplication.
2019-05-03Categorize WASI as an "OS" rather than as an "environment".Dan Gohman-2/+2
This distinction is fairly abstract, but in practice, the main advantage here is that LLVM's triple code considers WASI to be an OS, so this makes rustc agree with that.
2019-04-17Deny `internal` in stage0Mateusz Mikuła-1/+1
2019-04-11Add discr_index to multi-variant layoutsTyler Mandry-5/+7
We relax the assumption that the discriminant is always field 0, in preparations for layouts like generators where this is not going to be the case.
2019-04-06Rollup merge of #59624 - jethrogb:jb/sgx-unwind-syms, r=alexcrichtonMazdak Farrokhzad-0/+9
SGX target: Use linker option to avoid code CGU assignment kludge cc @VardhanThigle @faern
2019-04-04wasm32: Default to a "static" relocation modelAlex Crichton-0/+9
LLVM 9 is adding support for a "pic" relocation model for wasm code, which is quite different than the current model. In order to preserve the mode of compilation that we have today default to "static" to ensure that we don't accidentally start creating experimental relocatable binaries.
2019-04-04Disable stack probing for gnux32.CrLF0710-1/+2
2019-04-03Deny internal lints on non conflicting cratesflip1995-0/+1
- libarena - librustc_allocator - librustc_borrowck - librustc_codegen_ssa - librustc_codegen_utils - librustc_driver - librustc_errors - librustc_incremental - librustc_metadata - librustc_passes - librustc_privacy - librustc_resolve - librustc_save_analysis - librustc_target - librustc_traits - libsyntax - libsyntax_ext - libsyntax_pos
2019-04-01SGX target: Use linker option to avoid code CGU assignment kludgeJethro Beekman-0/+9
2019-03-31Rollup merge of #59519 - eddyb:layout-variants-refactor, r=oli-obkMazdak Farrokhzad-12/+16
rustc_target: factor out common fields of non-Single Variants. @tmandry and I were discussing ways to generalize the current variants/discriminant layout to allow more fields in the "`enum`" (or another multi-variant types, such as potentially generator state, in the future), shared by all variants, than just the tag/niche discriminant. This refactor should make it easier to extend multi-variant layouts, as nothing is duplicating anymore between "tagged enums" and "niche-filling enums". r? @oli-obk
2019-03-31Rollup merge of #59506 - JohnTitor:improve-mcount, r=nagisaMazdak Farrokhzad-39/+127
Use platform dependent mcount function close #59097 This pull-request is based on #57244 and [here](https://github.com/llvm-mirror/clang/search?q=MCountName&unscoped_MCountName). r? @nagisa
2019-03-31Use `u{1}` instead of `01`Yuki OKUSHI-16/+16
2019-03-30Add target_mcount optionYuki OKUSHI-39/+127
2019-03-29Add a new wasm32-unknown-wasi targetAlex Crichton-0/+114
This commit adds a new wasm32-based target distributed through rustup, supported in the standard library, and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem, networking, threads, etc. Instead it only provides the most basic of integration with the wasi syscalls, enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit, abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target, but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime], but more will surely emerge! In terms of future development of libstd, I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls, but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear, therefore, how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit, but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust, and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library, there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot, for example, provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management, process exit, and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way, if Rust and C are linked into the same WebAssembly binary they should work together, but that requires that the same C standard library is used. We also, however, want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind, there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go, a fully workable wasi binary pops out. This is incompatible with linking in C code, however, which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code, the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag, but the idea is that you're no longer using the provided static C runtime, but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols, but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:
2019-03-29rustc_target: factor out common fields of non-Single Variants.Eduard-Mihai Burtescu-12/+16
2019-03-20rustc: Allow using `clang` for wasm32 targetsAlex Crichton-51/+153
This commit adds support code for using `clang` directly to link the wasm32-unknown-unknown target. Currently the target is only really configured to link with LLD directly, but this ensures that `clang` can be configured as well. While not immediately useful in the near term it's likely that more wasm32 targets will pop up over time with Clang's new native support for WebAssembly in the 8.0.0 release. Getting support into rustc early should make it easier to experiment with these targets and try out various changes here and there.
2019-03-16Rollup merge of #58976 - phil-opp:patch-2, r=alexcrichtonkennytm-1/+1
Default to integrated `rust-lld` linker for UEFI targets The `x86_64-unknown-uefi` target was added in https://github.com/rust-lang/rust/pull/56769 with the linker defaulting to `lld-link`. This means that a system linker with that name is required for linking. I think defaulting to `rust-lld`, which is shipped with Rust, is a better default for the following reasons: - Most systems don't have `lld-link` installed, so it forces users to install it first. - The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu `apt install lld` leads to an executable named `lld-link-6.0`. - We already default to `rust-lld` for [many targets](https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=rust-lld&type=), including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like `x86_64-unknown-uefi` is the [only target](https://github.com/rust-lang/rust/search?q=lld-link&unscoped_q=lld-link) that uses `lld-link`.) cc @dvdhrm who added the target and @kkk669 who [proposed to use `rust-lld`](https://github.com/rust-lang/rust/pull/56769#issuecomment-461119648).
2019-03-16Rollup merge of #58941 - wzssyqa:master, r=alexcrichtonkennytm-0/+99
MIPS: add r6 support MIPS r6 is quite different with the previous version. It use some new target triples: mipsisa32r6-unknown-linux-gnu mipsisa32r6el-unknown-linux-gnu mipsisa64r6-unknown-linux-gnuabi64 mipsisa64r6el-unknown-linux-gnuabi64 This patch has been tested with Debian Port for mips64r6el, and the support of these triples also is included in llvm: https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
2019-03-08Rollup merge of #58080 - MikaelUrankar:freebsd_arm, r=sanxiynPietro Albini-0/+50
Add FreeBSD armv6 and armv7 targets
2019-03-06Default to integrated `rust-lld` linker for UEFI targetsPhilipp Oppermann-1/+1
2019-03-05MIPS: add r6 supportYunQiang Su-0/+99
MIPS r6 is quite different with the previous version. It use some new target triples: mipsisa32r6-unknown-linux-gnu mipsisa32r6el-unknown-linux-gnu mipsisa64r6-unknown-linux-gnuabi64 mipsisa64r6el-unknown-linux-gnuabi64 This patch has been tested with Debian Port for mips64r6el, and the support of these triples also is included in llvm: https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
2019-02-27Rename variadic to c_variadicDan Robertson-2/+2
Function signatures with the `variadic` member set are actually C-variadic functions. Make this a little more explicit by renaming the `variadic` boolean value, `c_variadic`.
2019-02-27Support defining C compatible variadic functionsDan Robertson-4/+15
Add support for defining C compatible variadic functions in unsafe rust with extern "C".
2019-02-20Search for target_triple.json only if builtin target not foundgnzlbg-6/+16
Before this commit, if the builtin target was found, but an error happened when instantiating it (e.g. validating the target specification file failed, etc.), then we ignored those errors and proceeded to try to find a `target_triple.json` file, and if that failed, reported that as an error. With this commit, if rustc is supposed to provide the builtin target, and something fails while instantiating it, that error will get properly propagated.
2019-02-15Auto merge of #58406 - Disasm:rv64-support, r=nagisabors-0/+64
Add riscv64{imac,gc}-unknown-none-elf targets Previous attempt by @fintelia: https://github.com/rust-lang/rust/pull/58012 Related: https://github.com/rust-embedded/wg/issues/218
2019-02-13Add FreeBSD armv6 and armv7 targetsMikaelUrankar-0/+50
2019-02-13target/uefi: clarify documentationDavid Rheinsberg-12/+17
This clarifies why FP-units are disabled on UEFI targets, as well as why we must opt into the NXCOMPAT feature. I did find some time to investigate why GRUB and friends disable FP on UEFI. The specification explicitly allows using MMX/SSE/AVX, but as it turns out it does not mandate enabling the instruction sets explicitly. Hence, any use of these instructions will trigger CPU exceptions, unless an application explicitly enables them (which is not an option, as these are global flags that better be controlled by the kernel/firmware). Furthermore, UEFI systems are allowed to mark any non-code page as non-executable. Hence, we must make sure to never place code on the stack or heap. So we better pass /NXCOMPAT to the linker for it to complain if it ever places code in non-code pages. Lastly, this fixes some typos in related comments.
2019-02-12Add riscv64gc-unknown-none-elf targetVadim Kaushan-0/+32
2019-02-12Add riscv64imac-unknown-none-elf targetVadim Kaushan-0/+32
2019-02-10rustc: doc commentsAlexander Regueiro-23/+23
2019-02-09Rollup merge of #58257 - taiki-e:librustc_target-2018, r=CentrilMazdak Farrokhzad-220/+221
librustc_target => 2018 Transitions `librustc_target` to Rust 2018; cc #58099 r? @Centril
2019-02-08librustc_target => 2018Taiki Endo-220/+221
2019-02-07Remove images' url to make it work even without internet connectionGuillaume Gomez-3/+1
2019-02-02Auto merge of #58060 - andre-richter:master, r=nagisabors-0/+1
targets: aarch64-unknown-none: Add +strict-align On AArch64, an unaligned access causes a synchronous exception. In the current state of the target, the compiler might generate unaligned accesses, see https://github.com/rust-embedded/rust-raspi3-tutorial/issues/10. Since this is a bare-metal target, it is possible that there is no exception handling in place (yet) to recover from this case, causing a binary to just silently fail. Add `+strict-align` to avoid this case.
2019-02-01targets: aarch64-unknown-none: Add +strict-alignAndre Richter-0/+1
On AArch64, an unaligned access causes a synchronous exception. In the current state of the target, the compiler might generate unaligned accesses, see https://github.com/rust-embedded/rust-raspi3-tutorial/issues/10. Since this is a bare-metal target, it is possible that there is no exception handling in place (yet) to recover from this case, causing a binary to just silently fail. Add `+strict-align` to avoid this case.
2019-01-28NVPTX: by-default use target cpu "sm_30"Denys Zariaiev-3/+3
2019-01-27Create `nvptx64-nvidia-cuda` target specificationDenys Zariaiev-0/+77
2019-01-27Auto merge of #57925 - fintelia:riscv-cas, r=nagisabors-1/+1
Enable RISC-V atomic compare and swap Fixes #56564
2019-01-26Enable RISC-V atomic compare and swapJonathan Behrens-1/+1
2019-01-25distinguish "no data" from "heterogeneous" for ABI purposesNiko Matsakis-19/+72
Also, add a testing infrastructure and tests that lets us dump layout.
2019-01-21Add powerpc64-unknown-freebsdYour Name-0/+23
2019-01-05Add a target option "merge-functions" taking values in ("disabled",Peter Jin-1/+65
"trampolines", or "aliases (the default)) to allow targets to opt out of the MergeFunctions LLVM pass. Also add a corresponding -Z option with the same name and values. This works around: https://github.com/rust-lang/rust/issues/57356 Motivation: Basically, the problem is that the MergeFunctions pass, which rustc currently enables by default at -O2 and -O3, and `extern "ptx-kernel"` functions (specific to the NVPTX target) are currently not compatible with each other. If the MergeFunctions pass is allowed to run, rustc can generate invalid PTX assembly (i.e. a PTX file that is not accepted by the native PTX assembler ptxas). Therefore we would like a way to opt out of the MergeFunctions pass, which is what our target option does. Related work: The current behavior of rustc is to enable MergeFunctions at -O2 and -O3, and also to enable the use of function aliases within MergeFunctions. MergeFunctions both with and without function aliases is incompatible with the NVPTX target. clang's "solution" is to have a "-fmerge-functions" flag that opts in to the MergeFunctions pass, but it is not enabled by default.
2018-12-25Remove licensesMark Rousskov-1580/+0
2018-12-23Rollup merge of #56979 - VardhanThigle:Vardhan/rust-sgx-unwind-support, ↵kennytm-19/+27
r=alexcrichton Adding unwinding support for x86_64_fortanix_unknown_sgx target. Unwinding support is provided by our port of LLVM's libunwind which is available from https://github.com/fortanix/libunwind/tree/release_50. libunwind requires support for rwlock and printing to stderr, which is only provided by `std` for this target. This poses two problems: 1) how to expose the `std` functionality to C and 2) dependency inversion. ### Exposing `std` For exposing the functionality we chose to expose the following symbols: * __rust_rwlock_rdlock * __rust_rwlock_wrlock * __rust_rwlock_unlock * __rust_print_err * __rust_abort Also, the following are needed from `alloc`: * __rust_alloc * __rust_dealloc #### Rust RWLock in C In `libunwind`, RWLock is initialized as a templated static variable: ```c pthread_rwlock_t DwarfFDECache<A>::_lock = PTHREAD_RWLOCK_INITIALIZER; ``` I don't know of a good way to use the Rust sys::rwlock::RWLock type and initializer there. We could have a static global variable in Rust, but that doesn't work with the templating. The variable needs to be initialized statically, since this target doesn't support the .init section. Currently, I just used a byte array and standard C array initialization. The mapping between this C type and the Rust type needs to be manually maintained. There is a compile-time check and a unit test to make sure the Rust versions of these C definitions match the actual Rust type. If any reviewer knows of a better solution, please do tell. ### Dependency inversion issue `std` depends on `panic_unwind` which depends on `libunwind`, and `libunwind` depends on `std`. This is not normally supported by Rust's linking system. Therefore we use raw C exports from `std` *and* `libunwind.a` is linked last in the target `post_link_objects` instead of being built as part of the Rust `libunwind`. Currently, all C exports are defined in `src/libstd/sys/sgx/rwlock.rs` to overcome LTO issues. Only the `__rust_rwlock_*` definitions *need* to live there for privacy reasons. Once again, if any reviewer knows of a better solution, please do tell. r? @alexcrichton
2018-12-19Adding unwinding support for x86_64_fortanix_unknown_sgx target.Vardhan Thigle-19/+27
2018-12-19Rollup merge of #56947 - hsivonen:neon, r=alexcrichtonPietro Albini-0/+98
Add targets thumbv7neon-linux-androideabi and thumbv7neon-unknown-linux-gnueabihf These two targets enable both thumb-mode and NEON for ARMv7 CPUs. This another attempt at #49902, which cannot be reopened. Between that PR and this one, some subrepos with C code whose build systems were failing went away.
2018-12-17Enable stack probes for UEFI imagesWonwoo Choi-0/+1
2018-12-17Auto merge of #56833 - nagisa:ios-fix, r=alexcrichtonbors-0/+2
Provide -isysroot with sdkroot for ios builds Necessary for the new XCode? Absolutely positively definitely untested… although I did ``` cargo rustc -- -Clink-arg=-isysroot -Clink-arg=$sdk_root ``` and stuff did compile for once.
2018-12-15Rollup merge of #56710 - jethrogb:jb/sgx-target-features, r=alexcrichtonPietro Albini-0/+1
Always set the RDRAND and RDSEED features on SGX Not sure if this is 100% correct. This [Intel article](https://software.intel.com/en-us/articles/intel-software-guard-extensions-tutorial-part-5-enclave-development) goes in great depth regarding using (untrusted) CPUID to see whether RDRAND/RDSEED is supported, and explains what happens to the enclave if the CPUID result is faked. I'd say that an implementation of SGX that doesn't make RDRAND available to the enclave is so severely limited/broken that it's ok if you get #UD in that case. The case is less clear for RDSEED, but it so far every processor released by Intel with SGX support also has RDSEED (including Gemini Lake). cc @briansmith
2018-12-15Rollup merge of #56769 - dvdhrm:uefi-target, r=alexcrichtonPietro Albini-0/+135
Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore, it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...). UEFI systems provide a very basic operating-system environment, meant to unify how systems are booted. It is tailored for simplicity and fast setup, as it is only meant to bootstrap other systems. For instance, it copies most of the ABI from Microsoft Windows, rather than inventing anything on its own. Furthermore, any complex CPU features are disabled. Only one CPU is allowed to be up, no interrupts other than the timer-interrupt are allowed, no process-separation is performed, page-tables are identity-mapped, ... Nevertheless, UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However, many other UEFI applications have emerged in the past, including network-boot, debug-consoles, and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added, but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore, liballoc works as well, if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike, none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore, several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-10 23:02:10 +0000