about summary refs log tree commit diff
path: root/src/librustc_target/spec
AgeCommit message (Collapse)AuthorLines
2020-08-30mv compiler to compiler/mark-7873/+0
2020-08-27Auto merge of #74941 - dylanmckay:replace-broken-avr-unknown-unknown-target, ↵bors-50/+58
r=oli-obk [AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target The `avr-unknown-unknown` target has never worked correctly, always trying to invoke the host linker and failing. It aimed to be a mirror of AVR-GCC's default handling of the `avr-unknown-unknown' triple (assume bare minimum chip features, silently skip linking runtime libraries, etc). This behaviour is broken-by-default as it will cause a miscompiled executable when flashed. This patch improves the AVR builtin target specifications to instead expose only a 'avr-unknown-gnu-atmega328' target. This target system is `gnu`, as it uses the AVR-GCC frontend along with avr-binutils. The target triple ABI is 'atmega328'. In the future, it should be possible to replace the dependency on AVR-GCC and binutils by using the in-progress AVR LLD and compiler-rt support. Perhaps at that point it would make sense to add an 'avr-unknown-unknown-atmega328' target as a better default when implemented. There is no current intention to add in-tree AVR target specifications for other AVR microcontrollers - this one can serve as a reference implementation for other devices via `rustc --print target-spec-json avr-unknown-gnu-atmega328p`. There should be no users of the existing 'avr-unknown-unknown' Rust target as a custom target specification JSON has always been recommended, and the avr-unknown-unknown target could never pass the linking step anyway.
2020-08-26Auto merge of #75843 - hermitcore:devel, r=nagisabors-6/+6
HermitCore switchs to relocatable binaries - switch to relocatbale binaries to realize ASLR - remove all dependencies to gcc
2020-08-24[AVR] Merge the 'freestanding' base target spec into AVR base target specDylan McKay-35/+21
The 'freestanding' module was only ever used for AVR. It was an unnecessary layer of abstraction. This commit merges the 'freestanding_base' module into 'avr_gnu_base'.
2020-08-24[AVR] Remove unnecessary arguments passed to the linker for GNU targetDylan McKay-4/+3
In general, linking with libc is not required, only libgcc is needed. As suggested in the code review, a better option for libc support is by building it into rust-lang/libc directly. This also removes the '-Os' argument to the linker, which is a NOP.
2020-08-24[AVR] Replace broken 'avr-unknown-unknown' target with ↵Dylan McKay-18/+41
'avr-unknown-gnu-atmega328' target The `avr-unknown-unknown` target has never worked correctly, always trying to invoke the host linker and failing. It aimed to be a mirror of AVR-GCC's default handling of the `avr-unknown-unknown' triple (assume bare minimum chip features, silently skip linking runtime libraries, etc). This behaviour is broken-by-default as it will cause a miscompiled executable when flashed. This patch improves the AVR builtin target specifications to instead expose only a 'avr-unknown-gnu-atmega328' target. This target system is `gnu`, as it uses the AVR-GCC frontend along with avr-binutils. The target triple ABI is 'atmega328'. In the future, it should be possible to replace the dependency on AVR-GCC and binutils by using the in-progress AVR LLD and compiler-rt support. Perhaps at that point it would make sense to add an 'avr-unknown-unknown-atmega328' target as a better default when implemented. There is no current intention to add in-tree AVR target specifications for other AVR microcontrollers - this one can serve as a reference implementation for other devices via `rustc --print target-spec-json avr-unknown-gnu-atmega328p`. There should be no users of the existing 'avr-unknown-unknown' Rust target as a custom target specification JSON has always been recommended, and the avr-unknown-unknown target could never pass the linking step anyway.
2020-08-23HermitCore switchs to relocatable binariesStefan Lankes-6/+6
- switch to relocatbale binaries to realize ASLR - remove all dependencies to gcc
2020-08-15Auto merge of #75483 - mati865:mingw-lld-flags, r=petrochenkovbors-67/+71
Add LLD flags for MinGW Tested locally and this now works: - `RUSTFLAGS="-Zlink-self-contained=yes -Clinker=rust-lld" cargo b` - `RUSTFLAGS="-Zlink-self-contained=no -Clinker=rust-lld -Zpre-link-arg=-Ld:/msys64/mingw64/x86_64-w64-mingw32/lib -Zpre-link-arg=-Ld:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.2.0 -Zpre-link-arg=crt2.o" cargo b` This is "harmless" part of the changes to make possible linking with bare LLD with windows-gnu target. More debatable changes should follow in next PRs soon.
2020-08-14Rework `rustc_serialize`Matthew Jasper-6/+6
- Move the type parameter from `encode` and `decode` methods to the trait. - Remove `UseSpecialized(En|De)codable` traits. - Remove blanket impls for references. - Add `RefDecodable` trait to allow deserializing to arena-allocated references safely. - Remove ability to (de)serialize HIR. - Create proc-macros `(Ty)?(En|De)codable` to help implement these new traits.
2020-08-13Add LLD flags for MinGWMateusz Mikuła-67/+71
2020-08-04Remove the `--no-threads` workaround for wasm targets.Dan Gohman-7/+0
Remove `--no-threads` from the wasm-ld command-line, which was a workaround for [an old bug] which was fixed in LLVM 9.0, and is no longer needed. Also, the `--no-threads` option has been [removed upstream]. [an old bug]: https://bugs.llvm.org/show_bug.cgi?id=41508 [removed upstream]: https://reviews.llvm.org/D76885
2020-07-29Change the target data layout to specify more valuesLokathor-1/+1
This does not actually alter the previously specified important parts, but apparently `rustc` cares about more layout components than `cargo-xbuild` ever did. This extends the data layout to be fully specified layout, as given in the error from issue #74767
2020-07-22Rollup merge of #74631 - petrochenkov:ehdr2, r=jonas-schievinkManish Goregaokar-0/+20
rustc_target: Add a target spec option for disabling `--eh-frame-hdr` Disable `--eh-frame-hdr` for targets that use an `ld`-like linker, but don't support that option. Do it through a target spec option rather than through hard-coding in `linker.rs`. The option is still enabled by default though. cc https://github.com/rust-lang/rust/pull/73564 Fixes https://github.com/rust-lang/rust/pull/73564#issuecomment-657011004 Fixes https://github.com/rust-lang/rust/pull/74625 Fixes https://github.com/rust-embedded/msp430-rt/issues/12
2020-07-22rustc_target: Add a target spec option for disabling `--eh-frame-hdr`Vadim Petrochenkov-0/+20
2020-07-20Add the aarch64-apple-darwin targetJake Goulding-1/+35
This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.
2020-07-19Rollup merge of #74419 - Lokathor:gba-target, r=jonas-schievinkManish Goregaokar-0/+63
Add a thumbv4t-none-eabi target (cc @ketsuban, one of the few other Rust users who programs for GBA.) --- **EDIT:** This is now a more general `thumbv4t-none-eabi` PR! See [this comment](https://github.com/rust-lang/rust/pull/74419#issuecomment-660391579) --- Now that the PSP officially has an official target within Rust, well as the lead of the `gba` crate I can't _not_ add a GBA target as well. I know that the [target tier policy](https://github.com/rust-lang/rfcs/pull/2803) isn't ratified and official, but I'll use it as an outline (cc @joshtriplett): * Designated Developer: Lokathor * Naming consistent with any existing targets * Doesn't create Rust project legal issues. * No license issues * Uses the standard Apache/mit license. * Rust tooling users don't have to accept any new licensing requirements * Does not support hosting rust tooling. * Doesn't require linking in proprietary code to obtain a functional binary. However, you will need to do some post-build steps to turn the ELF file into a usable GBA ROM (either for an emulator or for the actual hardware). * This is a `no_std` environment, without even a standard global allocator, so this adds no new code to `alloc` or `std`. * The process of building for this target is documented in the `gba` crate ([link](https://rust-console.github.io/gba/development-setup.html)). Well, the docs there are currently a little out of date, they're back on using `cargo-xbuild`, but the crate docs there will get updated once this target is available. * This places no new burden on any other targets * Does not break any existing targets. I'm not fully confident in specifying the same linker script for all possible projects, so I'm currently just not giving a linker script at all, and users can continue to select their own linker script by using `-C` to provide a linker arg. I added the file, and added it to the `supported_targets!` macro usage, and I think that's all there is to do.
2020-07-18remove unused importsLokathor-1/+1
2020-07-18Resolve https://github.com/rust-lang/rust/pull/74419#issuecomment-660518936Lokathor-14/+1
2020-07-17Make the new target a general thumbv4t target.Lokathor-13/+19
2020-07-16Resolve https://github.com/rust-lang/rust/pull/74419#discussion_r456139741Lokathor-2/+0
2020-07-16resolve https://github.com/rust-lang/rust/pull/74419#discussion_r456140272Lokathor-3/+0
2020-07-16Resolve https://github.com/rust-lang/rust/pull/74419#discussion_r456142514Lokathor-3/+0
2020-07-16Resolve https://github.com/rust-lang/rust/pull/74419#discussion_r456141344Lokathor-3/+0
2020-07-16fix the imports.Lokathor-1/+1
2020-07-16Add to supported_targets list.Lokathor-0/+1
2020-07-16Docs clarifications.Lokathor-5/+5
2020-07-16fill in all those options.Lokathor-11/+61
2020-07-16Remove leftover from emscripten fastcomp supportbjorn3-6/+0
This is no longer used since #63649
2020-07-16start GBA file.Lokathor-0/+30
2020-07-11don't mark linux kernel module targets as a unix environmentAlex Gaynor-1/+0
2020-07-10Avoid "whitelist"Tamir Duberstein-10/+10
Other terms are more inclusive and precise.
2020-07-08Avoid "blacklist"Tamir Duberstein-77/+85
Other terms are more inclusive and precise. Clippy still has a lint named "blacklisted-name", but renaming it would be a breaking change, so is left for future work. The target configuration option "abi-blacklist" has been depreciated and renamed to "unsupported-abis". The old name continues to work.
2020-06-27linker: Create GNU_EH_FRAME header by default when producing ELFsVadim Petrochenkov-14/+2
2020-06-26Rollup merge of #72937 - AdrianCX:master, r=nikomatsakisManish Goregaokar-2/+4
Fortanix SGX target libunwind build process changes Ticket: https://github.com/fortanix/rust-sgx/issues/174 LLVM related changes (merged): https://github.com/rust-lang/llvm-project/pull/57 Description: libunwind changes needed to run code in sgx environment via rust-sgx. Target that uses this in rust: x86_64-fortanix-unknown-sgx. Without this change, rust std for this toolchain is forced to use a precompiled library loaded via environment variable. With this change we act the same as musl target.
2020-06-24Update libunwind build process for x86_64-fortanix-unknown-sgx targetAdrian Cruceru-2/+4
2020-06-19Allow dynamic linking for iOS/tvOS targets.luxx4x-1/+0
2020-06-19Rollup merge of #70740 - haraldh:static-pie, r=petrochenkovRalf Jung-0/+1
Enabling static-pie for musl and make it the default for the x86_64-unknown-linux-musl target This is a quick implementation for https://github.com/rust-lang/rust/issues/70693 Opening it as a draft PR to gather some feedback, before I put more work in it. ```console ❯ cat hello.rs fn main() { println!("main = {:#x}", &main as *const _ as usize); } ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl ~/hello.rs ❯ ldd hello statically linked ❯ file hello hello: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=fec5cdc170f503a712a63a6958691ce5ce433654, with debug_info, not stripped ❯ ./hello main = 0x7f233ca30008 ❯ ./hello main = 0x7f9ddc529008 ❯ ./hello main = 0x7f1e5a224008 ❯ ./hello main = 0x7f4485c7c008 ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl -Z print-link-args ~/hello.rs "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-Wl,--eh-frame-hdr" "-m64" "-nostdlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/rcrt1.o" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o" "-L" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib" "hello.hello.7rcbfp3g-cgu.0.rcgu.o" "hello.hello.7rcbfp3g-cgu.1.rcgu.o" "hello.hello.7rcbfp3g-cgu.2.rcgu.o" "hello.hello.7rcbfp3g-cgu.3.rcgu.o" "hello.hello.7rcbfp3g-cgu.4.rcgu.o" "hello.hello.7rcbfp3g-cgu.5.rcgu.o" "-o" "hello" "hello.1nxjf9so94czdgcz.rcgu.o" "-Wl,--gc-sections" "-static-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0f9cb7646f9e2c34.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ba857f2f2e4e7187.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libhashbrown-58ba5e25bbdf9d29.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_alloc-886bfe43afa847dc.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace-fbfb8fe99f19a67b.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-85fa859e7d364cc9.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-07ab026cd3ec0d82.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-a8ec5932d92ea864.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcfg_if-0ba4cc2f38a198d5.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c1bb2b3ce4f78b7c.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-0ff673c1cf0d451a.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-c8ff2001db856926.rlib" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-2ae14177140eeca2.rlib" "-Wl,--end-group" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-4fd81b5ce1b08a9c.rlib" "-static" "-Wl,-Bdynamic" "/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o" ``` Closes https://github.com/rust-lang/rust/issues/70693 Closes https://github.com/rust-lang/rust/issues/53968
2020-06-17Auto merge of #69890 - lenary:lenary/riscv-frame-pointers, ↵bors-5/+0
r=hanna-kruppe,Mark-Simulacrum [RISC-V] Do not force frame pointers We have been seeing some very inefficient code that went away when using `-Cforce-frame-pointers=no`. For instance `core::ptr::drop_in_place` at `-Oz` was compiled into a function which consisted entirely of saving registers to the stack, then using the frame pointer to restore the same registers (without any instructions between the prolog and epilog). The RISC-V LLVM backend supports frame pointer elimination, so it makes sense to allow this to happen when using Rust. It's not clear to me that frame pointers have ever been required in the general case. In rust-lang/rust#61675 it was pointed out that this made reassembling stack traces easier, which is true, but there is a code generation option for forcing frame pointers, and I feel the default should not be to require frame pointers, given it demonstrably makes code size worse (around 10% in some embedded applications). The kinds of targets mentioned in rust-lang/rust#61675 are popular, but should not dictate that code generation should be worse for all RISC-V targets, especially as there is a way to use CFI information to reconstruct the stack when the frame pointer is eliminated. It is also a misconception that `fp` is always used for the frame pointer. `fp` is an ABI name for `x8` (aka `s0`), and if no frame pointer is required, `x8` may be used for other callee-saved values. --- I am partly posting this to get feedback from @fintelia who introduced the change to require frame pointers, and @hanna-kruppe who had issues with the original PR. I would understand if we wanted to remove this setting on only a subset of RISC-V targets, but my preference would be to remove this setting everywhere. There are more details on the code size savings seen in Tock here: https://github.com/tock/tock/pull/1660
2020-06-15Enable static-pie for the x86_64-unknown-linux-musl targetHarald Hoyer-0/+1
Fixes: https://github.com/rust-lang/rust/issues/70693
2020-06-15Rollup merge of #73086 - trevyn:apple-a7, r=nikicRalf Jung-3/+3
Rename "cyclone" to "apple-a7" per changes in upstream LLVM It looks like they intended to keep "cyclone" as a legacy option, but removed it from the list of subtarget features. This created a flood of warnings when targeting aarch64-apple-ios, and probably also created incorrectly optimized artifacts. See: https://reviews.llvm.org/D70779 https://reviews.llvm.org/D70779#C1703593NL568 LLVM 10 merged into master at: https://github.com/rust-lang/rust/pull/67759
2020-06-13Rollup merge of #73241 - mati865:mingw-libs-order-comment, r=petrochenkovDylan DPC-3/+4
Add/update comments about MinGW late_link_args
2020-06-13Add/update comments about MinGW late_link_argsMateusz Mikuła-3/+4
2020-06-12Auto merge of #69478 - avr-rust:avr-support-upstream, r=jonas-schievinkbors-0/+58
Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares, or make suggestions on the code patch itself.
2020-06-09Reoder order in which MinGW libs are linkedMateusz Mikuła-1/+1
2020-06-09[AVR] Rename the 'none_base' target spec module to 'freestanding_base'Dylan McKay-2/+2
2020-06-09[AVR] Add AVR platform supportJake Goulding-0/+58
2020-06-08Auto merge of #72655 - jethrogb:sgx-lvi-hardening, r=petrochenkovbors-1/+2
Enable LVI hardening for x86_64-fortanix-unknown-sgx This implements mitigations for the Load Value Injection vulnerability (CVE-2020-0551) for the `x86_64-fortanix-unknown-sgx` target by enabling new LLVM passes. More information about LVI and mitigations may be found at https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection. This PR unconditionally enables the mitigations for `x86_64-fortanix-unknown-sgx` since there is no available hardware that doesn't require the mitigations. This may be reconsidered in the future. * [x] This depends on https://github.com/rust-lang/compiler-builtins/pull/359/
2020-06-07Auto merge of #72904 - shepmaster:reduce-abi-symbol-hash-churn, ↵bors-4/+12
r=jonas-schievink,RalfJung Order the Rust and C ABIs first to reduce test churn
2020-06-07Enable LVI hardening for x86_64-fortanix-unknown-sgxJethro Beekman-1/+2
2020-06-07Rename "cyclone" to "apple-a7" per changes in upstream LLVMEden-3/+3
See: https://reviews.llvm.org/D70779 https://reviews.llvm.org/D70779#C1703593NL568 LLVM 10 merged into master at: https://github.com/rust-lang/rust/pull/67759
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-15 02:01:01 +0000