- 28 3月, 2021 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 08 11月, 2020 1 次提交
-
-
由 Vadim Petrochenkov 提交于
`target.target_endian` -> `target.endian` `target.target_c_int_width` -> `target.c_int_width` `target.target_os` -> `target.os` `target.target_env` -> `target.env` `target.target_vendor` -> `target.vendor` `target.target_family` -> `target.os_family` `target.target_mcount` -> `target.mcount`
-
- 07 11月, 2020 3 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
- 30 8月, 2020 1 次提交
-
-
由 mark 提交于
-
- 04 6月, 2020 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 13 4月, 2020 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 23 12月, 2019 1 次提交
-
-
由 Mark Rousskov 提交于
-
- 14 8月, 2019 1 次提交
-
-
由 Baoshan Pang 提交于
2. change armv7_wrs_vxworks to armv7_wrs_vxworks_eabihf. 3. use wr-** instead of vx-** 4. set PIE to false 5. code cleanup
-
- 16 7月, 2019 1 次提交
-
-
由 Baoshan Pang 提交于
r? @alexcrichton
-
- 08 2月, 2019 1 次提交
-
-
由 Taiki Endo 提交于
-
- 26 12月, 2018 1 次提交
-
-
由 Mark Rousskov 提交于
-
- 02 11月, 2018 1 次提交
-
-
由 Alex Crichton 提交于
This commit removes all jemalloc related submodules, configuration, etc, from the bootstrap, from the standard library, and from the compiler. This will be followed up with a change to use jemalloc specifically as part of rustc on blessed platforms.
-
- 26 4月, 2018 2 次提交
-
-
由 Irina Popa 提交于
-
由 Irina Popa 提交于
-
- 15 7月, 2017 1 次提交
-
-
由 Johannes Löthberg 提交于
Signed-off-by: NJohannes Löthberg <johannes@kyriasis.com>
-
- 11 7月, 2017 1 次提交
-
-
由 Johannes Löthberg 提交于
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: NJohannes Löthberg <johannes@kyriasis.com>
-
- 07 4月, 2017 1 次提交
-
-
由 Jorge Aparicio 提交于
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke the linker using a different interface. For example, by default rustc assumes that all the Linux targets will be linked using GCC. This makes it impossible to use LLD as a linker using just `-C linker=ld.lld` because that will invoke LLD with invalid command line arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't understand that; --gc-sections would be the right argument) With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker using a LD-like interface. This way, `rustc -C linker=ld.lld -Z linker-flavor=ld` will invoke LLD with the right arguments. `-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`, `gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD. This patch also changes target specifications. `linker-flavor` is now a mandatory field that specifies the *default* linker flavor that the target will use. This change also makes the linker interface *explicit*; before, it used to be derived from other fields like linker-is-gnu, is-like-msvc, is-like-emscripten, etc. Another change to target specifications is that the fields `pre-link-args`, `post-link-args` and `late-link-args` now expect a map from flavor to linker arguments. ``` diff - "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"], + "pre-link-args": { + "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"], + "ld": ["--as-needed", "-z,-noexecstack"], + }, ``` [breaking-change] for users of custom targets specifications
-
- 23 12月, 2016 1 次提交
-
-
由 Jeremy Soller 提交于
-
- 09 2月, 2016 1 次提交
-
-
由 Alex Crichton 提交于
The compiler currently vendors its own version of "llvm-ar" (not literally the binary but rather the library support) and uses it for all major targets by default (e.g. everything defined in `src/librustc_back/target`). All custom target specs, however, still search for an `ar` tool by default. This commit changes this default behavior to using the internally bundled llvm-ar with the GNU format. Currently all targets use the GNU format except for OSX which uses the BSD format (surely makes sense, right?), and custom targets can change the format via the `archive-format` key in custom target specs. I suspect that we can outright remove support for invoking an external `ar` utility, but I figure for now there may be some crazy target relying on that so we should leave support in for now.
-
- 21 1月, 2016 1 次提交
-
-
由 Ali Clark 提交于
-
- 22 12月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
Currently the standard library has some pretty complicated logic to detect whether #[thread_local] should be used or whether it's supported. This is also unfortunately not quite true for OSX where not all versions support the #[thread_local] attribute (only 10.7+ does). Compiling code for OSX 10.6 is typically requested via the MACOSX_DEPLOYMENT_TARGET environment variable (e.g. the linker recognizes this), but the standard library unfortunately does not respect this. This commit updates the compiler to add a `target_thread_local` cfg annotation if the platform being targeted supports the `#[thread_local]` attribute. This is feature gated for now, and it is only true on non-aarch64 Linux and 10.7+ OSX (e.g. what the module already does today). Logic has also been added to parse the deployment target environment variable.
-
- 26 9月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This commit updates the compiler to not attempt to use jemalloc for platforms where jemalloc is never enabled. Currently the compiler attempts to link in jemalloc based on whether `--disable-jemalloc` was specified at build time for the compiler itself, but this is only the right decision for the host target, not for other targets. This still leaves a hole open where a set of target libraries are downloaded which were built with `--disable-jemalloc` and the compiler is unaware of that, but this is a pretty rare case so it can always be fixed later.
-
- 15 8月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This commit is an implementation of [RFC 1183][rfc] which allows swapping out the default allocator on nightly Rust. No new stable surface area should be added as a part of this commit. [rfc]: https://github.com/rust-lang/rfcs/pull/1183 Two new attributes have been added to the compiler: * `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to indicate that it requires an allocator crate to be in scope. * `#![allocator]` - this is a indicator that the crate is an allocator which can satisfy the `needs_allocator` attribute above. The ABI of the allocator crate is defined to be a set of symbols that implement the standard Rust allocation/deallocation functions. The symbols are not currently checked for exhaustiveness or typechecked. There are also a number of restrictions on these crates: * An allocator crate cannot transitively depend on a crate that is flagged as needing an allocator (e.g. allocator crates can't depend on liballoc). * There can only be one explicitly linked allocator in a final image. * If no allocator is explicitly requested one will be injected on behalf of the compiler. Binaries and Rust dylibs will use jemalloc by default where available and staticlibs/other dylibs will use the system allocator by default. Two allocators are provided by the distribution by default, `alloc_system` and `alloc_jemalloc` which operate as advertised. Closes #27389
-
- 11 8月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This commit removes all morestack support from the compiler which entails: * Segmented stacks are no longer emitted in codegen. * We no longer build or distribute libmorestack.a * The `stack_exhausted` lang item is no longer required The only current use of the segmented stack support in LLVM is to detect stack overflow. This is no longer really required, however, because we already have guard pages for all threads and registered signal handlers watching for a segfault on those pages (to print out a stack overflow message). Additionally, major platforms (aka Windows) already don't use morestack. This means that Rust is by default less likely to catch stack overflows because if a function takes up more than one page of stack space it won't hit the guard page. This is what the purpose of morestack was (to catch this case), but it's better served with stack probes which have more cross platform support and no runtime support necessary. Until LLVM supports this for all platform it looks like morestack isn't really buying us much. cc #16012 (still need stack probes) Closes #26458 (a drive-by fix to help diagnostics on stack overflow)
-
- 11 7月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
We have previously always relied upon an external tool, `ar`, to modify archives that the compiler produces (staticlibs, rlibs, etc). This approach, however, has a number of downsides: * Spawning a process is relatively expensive for small compilations * Encoding arguments across process boundaries often incurs unnecessary overhead or lossiness. For example `ar` has a tough time dealing with files that have the same name in archives, and the compiler copies many files around to ensure they can be passed to `ar` in a reasonable fashion. * Most `ar` programs found do **not** have the ability to target arbitrary platforms, so this is an extra tool which needs to be found/specified when cross compiling. The LLVM project has had a tool called `llvm-ar` for quite some time now, but it wasn't available in the standard LLVM libraries (it was just a standalone program). Recently, however, in LLVM 3.7, this functionality has been moved to a library and is now accessible by consumers of LLVM via the `writeArchive` function. This commit migrates our archive bindings to no longer invoke `ar` by default but instead make a library call to LLVM to do various operations. This solves all of the downsides listed above: * Archive management is now much faster, for example creating a "hello world" staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also recently started requiring modification of rlibs, and linking a hello world dynamic library is now 2x faster. * The compiler is now one step closer to "hassle free" cross compilation because no external tool is needed for managing archives, LLVM does the right thing! This commit does not remove support for calling a system `ar` utility currently. We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward (so the system LLVM can be used wherever possible), and in these cases we must shell out to a system utility. All nightly builds of Rust, however, will stop needing a system `ar`.
-
- 20 5月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This value is the default anyway
-
- 28 4月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This commit adds support for x86_64-unknown-linux-musl as a target of the compiler. There's some comments in the commit about some of the more flavorful flags passed to the linker as it's not quite as trivial as the normal specs.
-
- 06 11月, 2014 1 次提交
-
-
由 Daniel Micay 提交于
-
- 04 11月, 2014 1 次提交
-
-
由 Corey Richardson 提交于
Removes all target-specific knowledge from rustc. Some targets have changed during this, but none of these should be very visible outside of cross-compilation. The changes make our targets more consistent. iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We used to accept any value of X greater than 1. i686 was released in 1995, and should encompass the bare minimum of what Rust supports on x86 CPUs. The only two windows targets are now i686-pc-windows-gnu and x86_64-pc-windows-gnu. The iOS target has been renamed from arm-apple-ios to arm-apple-darwin. A complete list of the targets we accept now: arm-apple-darwin arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf i686-apple-darwin i686-pc-windows-gnu i686-unknown-freebsd i686-unknown-linux-gnu mips-unknown-linux-gnu mipsel-unknown-linux-gnu x86_64-apple-darwin x86_64-unknown-freebsd x86_64-unknown-linux-gnu x86_64-pc-windows-gnu Closes #16093 [breaking-change]
-