[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 panic=immediate-abort
MCP: https://github.com/rust-lang/compiler-team/issues/909
This adds a new panic strategy, `-Cpanic=immediate-abort`. This panic strategy essentially just codifies use of `-Zbuild-std-features=panic_immediate_abort`. This PR is intended to just set up infrastructure, and while it will change how the compiler is invoked for users of the feature, there should be no other impacts.
In many parts of the compiler, `PanicStrategy::ImmediateAbort` behaves just like `PanicStrategy::Abort`, because actually most parts of the compiler just mean to ask "can this unwind?" so I've added a helper function so we can say `sess.panic_strategy().unwinds()`.
The panic and unwind strategies have some level of compatibility, which mostly means that we can pre-compile the sysroot with unwinding panics then the sysroot can be linked with aborting panics later. The immediate-abort strategy is all-or-nothing, enforced by `compiler/rustc_metadata/src/dependency_format.rs` and this is tested for in `tests/ui/panic-runtime/`. We could _technically_ be more compatible with the other panic strategies, but immediately-aborting panics primarily exist for users who want to eliminate all the code size responsible for the panic runtime. I'm open to other use cases if people want to present them, but not right now. This PR is already large.
`-Cpanic=immediate-abort` sets both `cfg(panic = "immediate-abort")` _and_ `cfg(panic = "abort")`. bjorn3 pointed out that people may be checking for the abort cfg to ask if panics will unwind, and also the sysroot feature this is replacing used to require `-Cpanic=abort` so this seems like a good back-compat step. At least for the moment. Unclear if this is a good idea indefinitely. I can imagine this being confusing.
The changes to the standard library attributes are purely mechanical. Apart from that, I removed an `unsafe` we haven't needed for a while since the `abort` intrinsic became safe, and I've added a helpful diagnostic for people trying to use the old feature.
To test that `-Cpanic=immediate-abort` conflicts with other panic strategies, I've beefed up the core-stubs infrastructure a bit. There is now a separate attribute to set flags on it.
I've added a test that this produces the desired codegen, called `tests/run-make-cargo/panic-immediate-abort-codegen/` and also a separate run-make-cargo test that checks that we can build a binary.
This commit updates the target specification of wasm targets to set the
`limit_rdylib_exports` value to `true` like it is on other native
platforms. This was originally not implemented long ago as `wasm-ld`
didn't have options for symbol exports, but since then it's grown a
`--export` flag and such to control this. A custom case is needed in the
linker implementation to handle wasm targets as `wasm-ld` doesn't
support linker scripts used on other targets, but other than that the
implementation is straightforward.
The goal of this commit is enable building dynamic libraries on
`wasm32-wasip2` which don't export every single symbol in the Rust
standard library. Currently, without otherwise control over symbol
visibility, all symbols end up being exported which generates
excessively large binaries because `--gc-sections` ends up doing nothing
as it's all exported anyway.
This schema is helpful for people writing custom target spec JSON. It
can provide autocomplete in the editor, and also serves as documentation
when there are documentation comments on the structs, as `schemars` will
put them in the schema.
A lot of places had special handling just in case they would get an
allocator module even though most of these places could never get one or
would have a trivial implementation for the allocator module. Moving all
handling of the allocator module to a single place simplifies things a
fair bit.
Making it participate in LTO would be incorrect if you compile a crate
as both a dylib (which needs it) and rlib (which must not include it) in
the same rustc invocation. With linker plugin LTO, the allocator shim
will still participate in LTO as it is safe to do so in that case.
Previously it would attempt to export the allocator shim even linking
for a crate type which pulls in the allocator shim from a dylib rather
than locally defining it.
Move exporting of profiler and sanitizer symbols to the LLVM backend
Only the LLVM backend needs those specific symbols exported and it only needs them to be exported for LTO, not from cdylibs in general.
CFI: Make `lto` and `linker-plugin-lto` work the same for `compiler_builtins`
Fixrust-lang/rust#142284 by ensuring that `#![no_builtins]` crates can still emit bitcode when proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto) is used.
Don't export them from cdylibs. There is no need to do so and it
complicates exported_non_generic_symbols. In addition the GCC backend
likely uses different symbols and may potentially not even need us to
explicitly tell it to export the symbols it needs.
rustc_codegen_ssa: More comprehensive RISC-V ELF flags
This change implements more conformant, more comprehensive RISC-V ELF flags handling when generating certain object files directly from rustc.
* Use `"zca"` instead of `"c"`
The "Zca" extension (a subset of "C") is the minimal configuration for compressed instructions to set `EF_RISCV_RVC` flag.
* Set TSO flag from `"ztso"`
The "Ztso" extension denotes that the program depends on the RVTSO (Total Store Ordering) memory consistency model, which is stronger than the standard RVWMO (Weak Memory Ordering) consistency model and on ELF targets, we need to set `EF_RISCV_TSO` flag.
This commit implements more conformant, more comprehensive RISC-V ELF
flags handling when generating certain object files directly from rustc.
* Use "zca" instead of "c"
The "Zca" extension (a subset of "C") is the minimal configuration
for compressed instructions to set `EF_RISCV_RVC` flag.
* Set TSO flag from "ztso"
The "Ztso" extension denotes that the program depends on the RVTSO
(Total Store Ordering) memory consistency model, which is stronger
than the standard RVWMO (Weak Memory Ordering) consistency model and
on ELF targets, we need to set `EF_RISCV_TSO` flag.
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`).
Make no_mangle on foreign items explicit instead of implicit
for a followup PR I'm working on I need some foreign items to mangle. I could add a new attribute: `no_no_mangle` or something silly like that but by explicitly putting `no_mangle` in the codegen fn attrs of foreign items we can default it to `no_mangle` and then easily remove it when we don't want it.
I guess you'd know about this r? `@bjorn3.` Shouldn't be too hard to review :)
Builds on rust-lang/rust#144655 which should merge first.
