rust/src/librustc_back/target/linux_base.rs, branch 1.26.2

Support both partial and full RELRO

2017-07-14T20:01:37+00:00

Signed-off-by: Johannes Löthberg

Add support for full RELRO

2017-07-11T12:22:12+00:00

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

-Z linker-flavor

2017-04-07T15:52:42+00:00

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

Correct target_family mess

2016-12-23T05:20:47+00:00

rustc: Use llvm-ar for custom targets by default

2016-02-08T18:27:03+00:00

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.

actively disable stack execution on linux and bsd

2016-01-21T02:50:48+00:00

rustc: Add feature-gated cfg(target_thread_local)

2015-12-22T06:05:37+00:00

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.

rustc: Don't use jemalloc when crossing to MSVC

2015-09-25T23:26:23+00:00

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.

rustc: Allow changing the default allocator

2015-08-14T22:13:10+00:00

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

Remove morestack support

2015-08-10T23:35:44+00:00

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)