| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add asm!() support for hexagon
|
|
tag/niche terminology cleanup
The term "discriminant" was used in two ways throughout the compiler:
* every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`.
* that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling).
After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`).
This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in https://github.com/rust-lang/rust/pull/72419.
(There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.)
r? @eddyb
|
|
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
|
|
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
|
|
GPRs only
|
|
Fixes: https://github.com/rust-lang/rust/issues/70693
|
|
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
|
|
Add/update comments about MinGW late_link_args
|
|
|
|
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.
|
|
|
|
This patch brings the AVR calling convention argument classification
logic in line with AVR Clang's behaviour.
AVR-Clang currently uses the `clang::DefaultABIInfo` ABI implementation.
This calling convention promotes all aggregates to indirect, no matter their
size.
It is also unnecessary to perform any integer width extension for AVR as
the minimum argument size matches the minimum describable size of
abi::Primitive::Int - 8 bits.
At some point in the future, an AVR-GCC compatible argument
classification implementation should be adopted in both Clang and Rust.
|
|
|
|
|
|
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/
|
|
r=jonas-schievink,RalfJung
Order the Rust and C ABIs first to reduce test churn
|
|
|
|
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
|
|
|
|
linker: Add a linker rerun hack for gcc versions not supporting -static-pie
Which mirrors the existing `-no-pie` linker rerun hack, but the logic is a bit more elaborated in this case.
If the linker (gcc or clang) errors on `-static-pie` we rerun in with `-static` instead.
We must also replace CRT objects corresponding to `-static-pie` with ones corresponding to `-static` in this case.
(One sanity check for CRT objects in target specs is also added as a drive-by fix.)
To do in the future: refactor all linker rerun hacks into separate functions and share more code with `add_(pre,post)_link_objects`.
This PR accompanies https://github.com/rust-lang/rust/pull/71804 and unblocks https://github.com/rust-lang/rust/pull/70740.
|
|
Rename all remaining compiler crates to use the `rustc_foo` pattern
libarena -> librustc_arena
libfmt_macros -> librustc_parse_format
libgraphviz -> librustc_graphviz
libserialize -> librustc_serialize
Closes https://github.com/rust-lang/rust/issues/71177 in particular.
|
|
|
|
|
|
Update the Fuchsia linker defaults
This updates the linker defaults aligning them with Clang. Specifically,
we use 4K pages on all platforms, we always use BIND_NOW, we prefer all
loadable segments be separate and page aligned, and we support RELR
relocations.
|
|
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.
This commit does ensure that the standard library is built with unwind
tables, so that users do not need to rebuild the standard library in
order to get a backtrace that includes standard library calls (which is
the original reason for forcing frame pointers).
|
|
|
|
NVPTX support for new asm!
This PR implements the new `asm!` syntax for the `nvptx64-nvidia-cuda` target.
r? @Amanieu
|
|
linker: Support `-static-pie` and `-static -shared`
This PR adds support for passing linker arguments for creating statically linked position-independent executables and "statically linked" shared libraries.
Therefore it incorporates the majority of https://github.com/rust-lang/rust/pull/70740 except for the linker rerun hack and actually flipping the "`static-pie` is supported" switch for musl targets.
|
|
|
|
In a recent change, 8b199222cc92667cd0e57595ad435cd0a7526af8,
adjustments were made to the data layout we pass to LLVM.
Unfortunately, the illumos target was missed in this change.
See also: https://github.com/rust-lang/rust/pull/67900
|
|
This commit attempts to improve reproducibility of builds on macOS by
exporting the `ZERO_AR_DATE=1` environment variable for all invocations
of the linker. While it looks like this env var is targeted at just the
`ar` command (which does actually read this) it appears that recent-ish
versions of the linker *also* read this environment variable. This
env var forces the linker to set a deterministic zero value for the
mtime in the N_OSO field of the object file.
Currently it's believe that older versions of the linker will simply
ignore this env var, while newer versions will read it and produce a
deterministic output for compilations with debuginfo.
Closes #47086
Closes #66568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=nikomatsakis,jethrogb,dingelish
rustc_target: Avoid an inappropriate use of `post_link_objects`
It isn't supposed to be used for linking libraries.
Also linking libunwind unconditionally (and not together with the `src/libunwind` crate) is suspicious.
@jethrogb @VardhanThigle
Could you verify that it works as expected?
|
|
Add target thumbv7a-uwp-windows-msvc
Add target spec for thumbv7a-uwp-windows-msvc, so that libraries written in Rust will have a chance to run on ARM-based devices with Windows 10.
So far I managed to create a proof-of-concept library for Universal Windows Platform apps to consume and it worked on a Windows Phone. However, building a standalone executable seemed troublesome due to `LLVM ERROR: target does not implement codeview register mapping` stuff (see also https://github.com/rust-lang/rust/issues/52659#issuecomment-408233322 ).
Steps to test:
1. Clone and build this version
```sh
git clone https://github.com/bdbai/rust.git
cd rust
python x.py build -i --target thumbv7a-uwp-windows-msvc --stage 1 src/libstd
rustup toolchain link arm-uwp-stage1 .\build\x86_64-pc-windows-msvc\stage1\
```
2. Create a new library crate
```sh
cargo new --lib arm-uwp-test
cd arm-uwp-test
```
3. Change `crate-type` in `Cargo.toml` to `staticlib`
```toml
[lib]
crate-type=["staticlib"]
```
4. Replace the following code in `src/lib.rs`
```rust
#[no_mangle]
pub extern "system" fn call_rust() -> i32 {
2333
}
```
5. Build the crate
```sh
cargo +arm-uwp-stage1 build -v --target thumbv7a-uwp-windows-msvc
```
6. `arm-uwp-test.lib` should appear in `target\thumbv7a-uwp-windows-msvc\debug`
To consume this library:
1. Make sure Visual Studio 2017 and Windows 10 SDK (10.0.17134 or above) are installed
2. Create a new Blank App (C++/WinRT) in Visual Studio 2017 (Visual Studio 2019 cannot deploy UWP apps to Windows Phone)
3. Go to Property Pages, and then Linker->Input->Additional Dependencies, add `arm-uwp-test.lib` produced just now
4. Manually declare function prototypes in `MainPage.h`
```c++
extern "C" {
int call_rust();
}
```
5. Replace the `ClickHandler` part in `MainPage.cpp`
```c++
myButton().Content(box_value(std::to_wstring(call_rust())));
```
6. Build and deploy this app to an ARM device running Windows 10. The app should run and show `2333` when the button is clicked.
|
|
|
|
|
|
|
|
linker: More systematic handling of CRT objects
Document which kinds of `crt0.o`-like objects we link and in which cases, discovering bugs in process.
`src/librustc_target/spec/crt_objects.rs` is the place to start reading from.
This PR also automatically contains half of the `-static-pie` support (https://github.com/rust-lang/rust/pull/70740), because that's one of the six cases that we need to consider when linking CRT objects.
This is a breaking change for custom target specifications that specify CRT objects.
Closes https://github.com/rust-lang/rust/issues/30868
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
