| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
[win] Use find-msvc-tools instead of cc to find the linker and rc on Windows
`find-msvc-tools` was factored out from `cc` to allow updating the use in `rustc_codegen_ssa` (finding the linker when running the Rust compiler) and `rustc_windows_rc` (finding the Windows Resource Compiler when running the Rust compiler) to be separate from the use in `rustc_llvm` (building LLVM as part of building the Rust compiler).
|
|
|
|
|
|
|
|
|
|
Add VEXos "linked files" support to `armv7a-vex-v5`
Third-party programs running on the VEX V5 platform need a linker script to ensure code and data are always placed in the allowed range `0x3800000-0x8000000` which is read/write/execute. However, developers can also configure the operating system (VEXos) to preload a separate file at any location between these two addresses before the program starts (as a sort of basic linking or configuration loading system). Programs have to know about this at compile time - in the linker script - to avoid placing data in a spot that overlaps where the linked file will be loaded. This is a very popular feature with existing V5 runtimes because it can be used to modify a program's behavior without re-uploading the entire binary to the robot controller.
It's important for Rust to support this because while VEXos's runtime user-exposed file system APIs may only read data from an external SD card, linked files are allowed to load data directly from the device's onboard storage.
This PR adds the `__linked_file_start` symbol to the existing VEX V5 linker script which can be used to shrink the stack and heap so that they do not overlap with a memory region containing a linked file. It expects the linked file to be loaded in the final N bytes of user RAM (this is not technically required but every existing runtime does it this way to avoid having discontinuous memory regions).
With these changes, a developer targeting VEX V5 might add a second linker script to their project by specifying `-Clink-arg=-Tcustom.ld` and creating the file `custom.ld` to configure their custom memory layout. The linker would prepend this to the builtin target linker script.
```c
/* custom.ld: Reserves 10MiB for a linked file. */
/* (0x7600000-0x8000000) */
__linked_file_length = 10M;
/* The above line is equivalent to -Clink-arg=--defsym=__linked_file_length=10M */
/* Optional: specify one or more sections that */
/* represent the developer's custom format. */
SECTIONS {
.linked_file_metadata (NOLOAD) : {
__linked_file_metadata_start = .;
. += 1M;
__linked_file_metadata_end = .;
}
.linked_file_data (NOLOAD) : {
__linked_file_data_start = .;
. += 9M;
__linked_file_data_end = .;
}
} INSERT AFTER .stack;
```
Then, using an external tool like the `vex-v5-serial` crate, they would configure the metadata of their uploaded program to specify the path of their linked file and the address where it should be loaded into memory (in the above example, `0x7600000`).
|
|
|
|
The exact reasoning why we do not always pass the SDK root when linking
on macOS eludes me, but I suspect it's because we want to support
compiler drivers which do not support the `-isysroot` option.
Since we now pass the SDK root via the environment variable SDKROOT,
compiler drivers that don't support it can just ignore it.
Similarly, since we only warn when xcrun fails, users that expect their
compiler driver to provide the SDK location can do so now.
|
|
This is more in-line with what Apple's tooling expects, and allows us to
better support custom compiler drivers (such as certain Homebrew and
Nixpkgs compilers) that prefer their own `-isysroot` flag.
Effectively, we now invoke the compiler driver as-if it was invoked as
`xcrun -sdk $sdk_name $tool`.
|
|
Reduce indentation and avoid needless checks (checking the target OS and
vendor is unnecessary).
|
|
r=wesleywiser
Add diagnostic explaining STATUS_STACK_BUFFER_OVERRUN not only being used for stack buffer overruns if link.exe exits with that exit code
`STATUS_STACK_BUFFER_OVERRUN` is also used for fast abnormal program termination, e.g. by abort(). Emit a special diagnostic to let people know that this most likely doesn't indicate a stack buffer overrun.
This doesn't look up the crash report in the event log to determine what the fast fail error code is. This is due to the way crashes are logged: When a process crash happens, the system logs an "Application Error" event, which contains the exit code and the process ID, but not the fast fail error code. A second event by Windows Error Reporting does contain that fast fail code, but not the process ID - but that event is not emitted at process exit, but when WER has dealt with it (on my system, it happens roughly two seconds later), so querying the code would have to read the `IntegratorReportId`, wait two seconds or potentially longer for the WER event with the same `ReportID`, and read out the code. (Also, that second event doesn't happen if WER is disabled.)
Fixes rust-lang/rust#100519.
|
|
|
|
used for stack buffer overruns if link.exe exits with that exit code
`STATUS_STACK_BUFFER_OVERRUN` is also used for fast abnormal program
termination, e.g. by abort(). Emit a special diagnostic to let people
know that this most likely doesn't indicate a stack buffer overrun.
|
|
|
|
|
|
|
|
|
|
Now that `#[used(linker)]` is the default on ELF, we don't need to use the
`-znostart-stop-gc` link-arg workaround to match bfd's behavior when
using lld.
|
|
This stabilizes a subset of the `-Clinker-features` components on x64 linux:
the lld opt-out.
The opt-in is not stabilized, as interactions with other stable flags require
more internal work, but are not needed for stabilizing using rust-lld by default.
Similarly, since we only switch to rust-lld on x64 linux, the opt-out is
only stabilized there. Other targets still require `-Zunstable-options`
to use it.
|
|
|
|
Also avoid creating and cloning sysroot unnecessarily.
|
|
In a PR to emit warnings on misuse of `--print native-static-libs`,
we did not consider the matter of composing parts of build systems.
If you are not directly invoking rustc, it can be difficult to know
when you will in fact compile a staticlib, so making sure everyone
uses `--print native-static-lib` correctly can be just a nuisance.
This reverts the following commits:
- f66787a08d57dc1296619b314d2be596085bfeef
- 72a9219e82c157041bfc8dfd378c9cb2b09c0650
- 98bb597c05c32365abbd6898f278b097352774ed
- c59b70841c36277464b51161e3fcf12dfcb667e0
Next cycle we can reland a slightly more narrowly focused variant or one
that focuses on `--emit` instead of `--print native-static-libs`.
But in its current state, I am not sure the warning is very useful.
|
|
r=workingjubilee,saethlin
Move metadata object generation for dylibs to the linker code
This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.
Prerequisite of https://github.com/rust-lang/rust/issues/96708.
|
|
[AIX] strip underlying xcoff object
When stripping, we need to strip the archive member first before archiving. Otherwise, the shared library remain untouched, only the archive symbol table will be modified.
|
|
Make #[used(linker)] the default on ELF too
`#[used]` currently is an alias for `#[used(linker)]` on all platforms except ELF based ones where it is an alias for `#[used(compiler)]`. The latter has surprising behavior and the LLVM LangRef explicitly states that it "should only be used in rare circumstances, and should not be exposed to source languages." [^2]
The reason `#[used]` still was an alias to `#[used(compiler)]` on ELF is because the gold linker has issues with it. Luckily gold has been deprecated with GCC 15 [^1] and seems to be unable to bootstrap rustc anyway [^3]. As such we shouldn't really care about supporting gold.
This would also allow re-enabling start-stop-gc with lld.
cc https://github.com/rust-lang/rust/issues/93798
Likely fixes https://github.com/rust-lang/rust/issues/85045
[^1]: https://lists.gnu.org/archive/html/info-gnu/2025-02/msg00001.html
[^2]: https://llvm.org/docs/LangRef.html#the-llvm-compiler-used-global-variable
[^3]: https://github.com/rust-lang/rust/issues/139425
|
|
#[used] currently is an alias for #[used(linker)] on all platforms
except ELF based ones where it is an alias for #[used(compiler)]. The
latter has surprising behavior and the LLVM LangRef explicitly states
that it "should only be used in rare circumstances, and should not be
exposed to source languages."
The reason #[used] still was an alias to #[used(compiler)] on ELF is
because the gold linker has issues with it. Luckily gold has been
deprecated with GCC 15 and seems to be unable to bootstrap rustc anyway.
As such we shouldn't really care about supporting gold.
|
|
This deduplicates some code between codegen backends and may in the
future allow adding extra metadata that is only known at link time.
|
|
And move passing it to the linker to the driver code.
|
|
Warn when gold was used as the linker
gold has been deprecated recently and is known to behave incorrectly around Rust programs, including miscompiling `#[used(linker)]`. Tell people to switch to a different linker instead.
closes rust-lang/rust#141748
r? bjorn3
|
|
gold has been deprecated recently and is known to behave incorrectly
around Rust programs, including miscompiling `#[used(linker)]`.
Tell people to switch to a different linker instead.
Co-Authored-By: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
It looks like this was added 6 years ago because of issues with the
MacOS linker. MacOS got a new linker in the meantime, so that should
probably be resolved now. Hopefully.
|
|
Emit warning while outputs is not exe and prints linkage info
cc #137384
```bash
$ rustc +stage1 /dev/null --print native-static-libs --crate-type staticlib --emit metadata
warning: skipping link step due to conflict: cannot output linkage information without emitting executable
note: consider emitting executable to print link information
warning: 1 warning emitted
```
|
|
|
|
|
|
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
If creating a temporary directory fails with permission denied then retry with backoff
On Windows, if creating a temporary directory fails with permission denied then use a retry/backoff loop. This hopefully fixes a recuring error in our CI.
cc ```@jieyouxu,``` https://github.com/rust-lang/rust/issues/133959
|
|
On Windows, if creating a temporary directory fails with permission denied then use a retry/backoff loop. This hopefully fixes a recuring error in our CI.
|
|
|
|
|
|
|
|
|
|
|
|
Also convert OSVersion into a proper struct for better type-safety.
|
|
Rename `is_like_osx` to `is_like_darwin`
Replace `is_like_osx` with `is_like_darwin`, which more closely describes reality (OS X is the pre-2016 name for macOS, and is by now quite outdated; Darwin is the overall name for the OS underlying Apple's macOS, iOS, etc.).
``@rustbot`` label O-apple
r? compiler
|
|
|
|
|
