| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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.
|
|
|
|
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).
|
|
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
|
|
Introduce `enum CodeModel` instead.
|
|
Add built in PSP target
This adds a new target, `mipsel-sony-psp`, corresponding to the Sony PSP. The linker script is necessary to handle special sections, which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended.
The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD.
The `stdarch` submodule was also updated in order for `libcore` to build successfully.
[rust-psp]: https://github.com/overdrivenpotato/rust-psp
[here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in
|
|
This absolves previous licensing issues.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
rustllvm: Use .init_array rather than .ctors
LLVM TargetMachines default to using the (now-legacy) .ctors
representation of init functions. Mixing .ctors and .init_array
representations can cause issues when linking with lld.
This happens in practice for:
* Our profiling runtime which is currently implicitly built with
.init_array since it is built by clang, which sets this field.
* External C/C++ code that may be linked into the same process.
Fixes: #71233
|
|
The App Store performs certain sanity checks on bitcode, including that
an acceptable set of command line arguments was used when compiling a
given module. For Rust code to be distributed on the app store with
bitcode rustc must pretend to have the same command line arguments.
|
|
At this time Apple recommends Bitcode be included for iOS apps, and
requires it for tvOS. It is unlikely that a developer would want to
disable bitcode when building for these targets, yet by default it will
not be generated. This presents a papercut for developers on those
platforms.
Introduces a new TargetOption boolean key for specific triples to
indicate that bitcode should be generated, even if cargo attempts to
optimise with -Cembed-bitcode=no.
|
|
Disable localization for all linkers
We previously disabled non-English output from `link.exe` due to encoding issues (#35785).
In https://github.com/rust-lang/rust/pull/70740 it was pointed out that it also prevents correct inspection of the linker output, which we have to do occasionally.
So this PR disables localization for all linkers.
|
|
LLVM TargetMachines default to using the (now-legacy) .ctors
representation of init functions. Mixing .ctors and .init_array
representations can cause issues when linking with lld.
This happens in practice for:
* Our profiling runtime which is currently implicitly built with
.init_array since it is built by clang, which sets this field.
* External C/C++ code that may be linked into the same process.
To support legacy systems which may use .ctors, targets may now specify
that they use .ctors via the use_ctors attribute which defaults to
false.
For debugging and manual control, -Z use-ctors-section=yes/no will allow
manual override.
Fixes: #71233
|
|
|
|
Introduce `enum TlsModel` instead.
|
|
Introduce `enum RelocModel` instead.
|
|
These are changes that would be needed if we add `#[must_use]` to
`Option::map`, per #71484.
|
|
Add illumos triple
This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions, several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target.
Work originally started by @jasonbking, with subsequent additions by @pfmooney and @jclulow.
|
|
Co-Authored-By: Jason King <jason.brian.king@gmail.com>
Co-Authored-By: Joshua M. Clulow <jmc@oxide.computer>
|
|
|
|
and inherit both `windows_msvc_base` and `uefi_msvc_base` from it.
|
|
|
|
|
|
|
|
The old naming is from ancient times when there was no MSVC support.
Also `uefi_base` -> `uefi_msvc_base`.
It will inherit from `msvc_base` in a future commit, plus a GNU UEFI target is also potentially possible.
|
|
|
|
as much as possible.
|
|
The differences if they are discovered will need to be explicitly documented
|
|
[windows] Add testscase for self-contained executables and fix pthread linking
Fixes https://github.com/rust-lang/rust/issues/71061
|
|
|
|
|
|
danielframpton:aarch64-windows-panic-unwind-default, r=alexcrichton
Make panic unwind the default for aarch64-*-windows-msvc targets
With the llvm fixes from rust-lang/llvm-project#45 (included as a submodule change) we can enable unwinding by default for these targets.
Fixes #65313
There are still a small number of test failures for which we can open individual issues.
r? @alexcrichton
|
|
|
