summary refs log tree commit diff
path: root/src/librustc_back
AgeCommit message (Collapse)AuthorLines
2017-12-21explanatory note for the workaroundMathieu Poumeyrol-0/+3
2017-12-21disable jemalloc on exectuable for ios targetsMathieu Poumeyrol-0/+1
2017-11-19std: Add a new wasm32-unknown-unknown targetAlex Crichton-0/+131
This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
2017-11-11Control LLVM's TrapUnreachable feature through rustc's TargetOptions.Dan Gohman-0/+7
2017-11-08std: Remove `rand` crate and moduleAlex Crichton-3/+3
This commit removes the `rand` crate from the standard library facade as well as the `__rand` module in the standard library. Neither of these were used in any meaningful way in the standard library itself. The only need for randomness in libstd is to initialize the thread-local keys of a `HashMap`, and that unconditionally used `OsRng` defined in the standard library anyway. The cruft of the `rand` crate and the extra `rand` support in the standard library makes libstd slightly more difficult to port to new platforms, namely WebAssembly which doesn't have any randomness at all (without interfacing with JS). The purpose of this commit is to clarify and streamline randomness in libstd, focusing on how it's only required in one location, hashmap seeds. Note that the `rand` crate out of tree has almost always been a drop-in replacement for the `rand` crate in-tree, so any usage (accidental or purposeful) of the crate in-tree should switch to the `rand` crate on crates.io. This then also has the further benefit of avoiding duplication (mostly) between the two crates!
2017-11-03Fix error message for invalid code/reloc modelsAmanieu d'Antras-0/+6
2017-10-25Disable jemalloc for sparcv9-sun-solarisbgermann-0/+1
Similar to #36994, rust programs segfault on SPARC64 Solaris machines.
2017-10-15Auto merge of #45224 - malbarbo:x32, r=alexcrichtonbors-0/+36
Add x86_64-unknown-linux-gnux32 target This adds X32 ABI support for Linux on X86_64. Let's package and dist it so we can star testing libc, libstd, etc. Fixes https://github.com/rust-lang/rfcs/issues/1339
2017-10-14Auto merge of #45102 - petrochenkov:noar, r=alexcrichtonbors-41/+0
cleanup: rustc doesn't use an external archiver cc https://github.com/rust-lang/rust/pull/45090 r? @alexcrichton
2017-10-11Add x86_64-unknown-linux-gnux32 targetMarco A L Barbosa-0/+36
2017-10-09rustc: Allow target-specific default cgusAlex Crichton-0/+11
Some targets, like msp430 and nvptx, don't work with multiple codegen units right now for bugs or fundamental reasons. To expose this allow targets to express a default. Closes #45000
2017-10-09cleanup: rustc doesn't use an external archiverVadim Petrochenkov-41/+0
2017-10-09Auto merge of #45041 - est31:master, r=alexcrichtonbors-52/+0
Remove support for the PNaCl target (le32-unknown-nacl) This removes support for the `le32-unknown-nacl` target which is currently supported by rustc on tier 3. Despite the "nacl" in the name, the target doesn't output native code (x86, ARM, MIPS), instead it outputs binaries in the PNaCl format. There are two reasons for the removal: * Google [has announced](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html) deprecation of the PNaCl format. The suggestion is to migrate to wasm. Happens we already have a wasm backend! * Our PNaCl LLVM backend is provided by the fastcomp patch set that the LLVM fork used by rustc contains in addition to vanilla LLVM (`src/llvm/lib/Target/JSBackend/NaCl`). Upstream LLVM doesn't have PNaCl support. Removing PNaCl support will enable us to move away from fastcomp (#44006) and have a lighter set of patches on top of upstream LLVM inside our LLVM fork. This will help distribution packagers of Rust. Fixes #42420
2017-10-08Rollup merge of #45094 - japaric:strict-align, r=alexcrichtonkennytm-5/+5
enable strict alignment (+strict-align) on ARMv6 As discovered in #44538 ARMv6 devices may or may not support unaligned memory accesses. ARMv6 Linux *seems* to have no problem with unaligned accesses but this is because the kernel is stepping in to fix each unaligned memory access -- this incurs in a performance penalty. This commit enforces aligned memory accesses on all our in-tree ARM targets that may be used with ARMv6 devices. This should improve performance of Rust programs on ARMv6 devices. For the record, clang also applies this attribute when targeting ARMv6 devices that are not running Darwin or NetBSD. closes #44538 r? @alexcrichton
2017-10-07enable strict alignment (+strict-align) on ARMv6Jorge Aparicio-5/+5
As discovered in #44538 ARMv6 devices may or may not support unaligned memory accesses. ARMv6 Linux *seems* to have no problem with unaligned accesses but this is because the kernel is stepping in to fix each unaligned memory access -- this incurs in a performance penalty. This commit enforces aligned memory accesses on all our in-tree ARM targets that may be used with ARMv6 devices. This should improve performance of Rust programs on ARMv6 devices. For the record, clang also applies this attribute when targeting ARMv6 devices that are not running Darwin or NetBSD.
2017-10-05Remove nacl from librustc_backest31-52/+0
2017-10-02Allow atomic operations up to 32 bitsJames Munns-2/+6
The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides [user space helpers](https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt) which can be used to perform atomic operations. When linked with `libc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics. As this target is specifically `linux` and `gnueabi`, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all. I have used this change in a custom target (along with `xargo`) to build `std`, as well as a number of higher level crates.
2017-09-30rustc: Use 16bit c_int for msp430Daniel Klauer-1/+1
Fix regression from c2fe69b9, where main() signature was changed from using 16bit isize to 32bit c_int for argc parameter/result.
2017-09-30rustc: Specify c_int width for each targetDaniel Klauer-0/+75
(all i32 for now, as in liblibc)
2017-09-23add aarch64-unknown-linux-musl targetBen Cressey-0/+37
Signed-off-by: Ben Cressey <bcressey@amazon.com> Signed-off-by: Tom Kirchner <tjk@amazon.com>
2017-09-19rework the README.md for rustc and add other readmesNiko Matsakis-0/+6
This takes way longer than I thought it would. =)
2017-09-15Require +thumb-mode to generate thumb2 code for Android/armv7-aMakoto Kato-1/+1
2017-09-08Add `TargetOptions::min_global_align`, with s390x at 16-bitJosh Stone-0/+7
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.
2017-08-26Rollup merge of #44091 - kallisti5:haiku-fix, r=eddybCorey Farwell-1/+0
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.
2017-08-25haiku/librustc_back: Remove incorrect no_integrated_asAlexander von Gluck IV-1/+0
* Makes rust bootstrap incorrectly search for xxx.s vs xxx.0.s * Not needed or incorrect fix for another issue.
2017-08-25*: remove crate_{name,type} attributesTamir Duberstein-3/+0
Fixes #41701.
2017-08-24Auto merge of #44011 - TobiasSchaffner:improved_target_spec_clean, ↵bors-6/+56
r=alexcrichton 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`.
2017-08-22Support dynamic linking for musl-based targetsSamuel Holland-7/+0
Note that this commit does not affect mips-musl targets, as they do not inherit from linux_musl_base.
2017-08-22Introduce target feature crt_static_allows_dylibsSamuel Holland-0/+6
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.
2017-08-22Introduce temporary target feature crt_static_respectedSamuel Holland-0/+8
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".
2017-08-22Return L4Re TargetOptions as a Result type instead of panicTobias Schaffner-6/+6
If the environment variable L4RE_LIBDIR ist not set an Error will be returned wrapped in a result type instead of a panic.
2017-08-22L4Re Target: Add the needed Libraries and locate themSebastian Humenda-2/+52
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>
2017-08-19rustc: Remove some dead codeVadim Petrochenkov-43/+2
2017-08-16Enable unwinding panics on RedoxIan Douglas Scott-2/+1
2017-08-15use field init shorthand EVERYWHEREZack M. Davis-8/+8
Like #43008 (f668999), but _much more aggressive_.
2017-08-04Add L4Re Support in librustc_backTobias Schaffner-0/+66
Add support for x86_64-unknown-l4re-uclibc target, which covers the L4 Runtime Environment.
2017-07-22rustc: Add some build scripts for librustc cratesAlex Crichton-0/+15
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.
2017-07-19Pass debugging arguments to emccThomas Lively-1/+4
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.
2017-07-18Implement FromStr for RelroLevel rather than duplicating the matchJohannes Löthberg-4/+17
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
2017-07-14Make partial RELRO default on ppc64 due to segfaultJohannes Löthberg-1/+5
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>
2017-07-14Support both partial and full RELROJohannes Löthberg-21/+63
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
2017-07-11Add support for full RELROJohannes Löthberg-0/+13
This commit adds support for full RELRO, and enables it for the platforms I know have support for it. Full RELRO makes the PLT+GOT data read-only on startup, preventing it from being overwritten. http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html Fixes rust-lang/rust#29877. Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
2017-07-07Auto merge of #43099 - japaric:msp430, r=alexcrichtonbors-0/+55
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
2017-07-06add a built-in MSP430 targetJorge Aparicio-0/+55
2017-07-06rustc: Implement stack probes for x86Alex Crichton-0/+31
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.
2017-07-05rustc: Implement the #[global_allocator] attributeAlex Crichton-33/+23
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
2017-06-24Auto merge of #42784 - tlively:wasm-bot, r=alexcrichtonbors-0/+33
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.
2017-06-23Add Target (de)serialization for environment varsThomas Lively-0/+28
Also turn WebAssembly backend back on in its builder.
2017-06-23rustc: Enable #[thread_local] for WindowsAlex Crichton-0/+1
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.
2017-06-22Add target option for linker environment variablesThomas Lively-0/+5
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-27 23:45:50 +0000