Align VEX V5 boot routine to 4 bytes
This PR fixes an alignment issue with the initialization routine on the VEX V5 target.
Previously, if the `.text` output section contained any functions aligned to more than four bytes, the linker would add padding bytes before the beginning of `.text` rather than changing the position of the aligned function inside the section itself. This is an issue because the entry point for the program needs to be located at `0x3800_0020` on this platform and the addition of padding could cause it to be moved.
To fix this, I've forced the start address of the `.text` section to be aligned to 4 bytes so that the entry point is placed consistently. Items inside the section can still be aligned to values larger than this.
Extend attribute deduction to determine whether parameters using
indirect pass mode might have their address captured. Similarly to
the deduction of `readonly` attribute this information facilitates
memcpy optimizations.
Fix backtraces with `-C panic=abort` on qnx; emit unwind tables by default
While syncing https://github.com/rust-lang/rust/pull/143613 into Ferrocene as part of https://github.com/ferrocene/ferrocene/pull/1803, we noted a failure on our QNX targets:
```
---- [ui] tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs stdout ----
error: test did not exit with success! code=Some(134) so test would pass with `run-crash`
status: exit status: 134
command: RUSTC="/home/ci/project/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" RUST_TEST_THREADS="1" "/home/ci/project/build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-client" "run" "0" "/home/ci/project/build/x86_64-unknown-linux-gnu/test/ui/panics/panic-abort-backtrace-without-debuginfo/a"
--- stdout -------------------------------
uploaded "/home/ci/project/build/x86_64-unknown-linux-gnu/test/ui/panics/panic-abort-backtrace-without-debuginfo/a", waiting for result
died due to signal 6
------------------------------------------
--- stderr -------------------------------
thread 'main' (1) panicked at /home/ci/project/tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs:39:9:
ERROR: no `this_function_must_be_in_the_backtrace` in stderr! actual stderr:
thread 'main' (1) panicked at /home/ci/project/tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs:27:5:
generate panic backtrace
stack backtrace:
0: 0x4e66a53643 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h55e010263b1e3169
1: 0x4e66a68cd2 - core::fmt::write::h0d6e2e8752abc333
2: 0x4e66a16919 - std::io::Write::write_fmt::h71c4c024d832b384
3: 0x4e66a1f8e2 - std::sys::backtrace::BacktraceLock::print::hdd80dfdf90bb7100
4: 0x4e66a221e0 - std::panicking::default_hook::{{closure}}::h77758f25a686500f
5: 0x4e66a21f69 - std::panicking::default_hook::ha63f7d476af6c267
6: 0x4e66a22999 - std::panicking::panic_with_hook::h3a36a8a0f0dd8ccd
7: 0x4e66a21cac - std::panicking::begin_panic::{{closure}}::h570dedb92e232392
8: 0x4e66a1fa69 - std::sys::backtrace::__rust_end_short_backtrace::h5366eec354f92733
9: 0x4e669f9589 - std::panicking::begin_panic::h04a4bd4c33dd4056
10: 0x4e66a00aca - panic_abort_backtrace_without_debuginfo::and_this_function_too::h5b034b94cbe9c3d3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
------------------------------------------
---- [ui] tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs stdout end ----
failures:
[ui] tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs
test result: FAILED. 19958 passed; 1 failed; 328 ignored; 0 measured; 0 filtered out; finished in 1827.71s
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-pc-nto-qnx710
Build completed unsuccessfully in 0:43:28
Exited with code exit status 1
```
This patch applies the same fix as the one found in https://github.com/rust-lang/rust/pull/143613 of adding the `default_uwtable: true` to the target.
I've run it locally, when https://github.com/ferrocene/ferrocene/pull/1803 merges we'll know it has passed within our CI, which is about a close an analog as I can offer to Rust.
Add vsx register support for ppc inline asm, and implement preserves_flag option
This should address the last(?) missing pieces of inline asm for ppc:
* Explicit VSX register support. ISA 2.06 (POWER7) added a 64x128b register overlay extending the fpr's to 128b, and unifies them with the vmx (altivec) registers. Implementations details within gcc/llvm percolate up, and require using the `x` template modifier. I have updated the inline asm to implicitly include this for vsx arguments which do not specify it. ~~Support for the gcc codegen backend is still a todo.~~
* Implement the `preserves_flags` option. All ABI's, and all ISAs store their flags in `cr`, and the carry bit lives inside `xer`. The other status registers hold sticky bits or control bits which do not affect branch instructions.
There is some interest in the e500 (powerpcspe) port. Architecturally, it has a very different FP ISA, and includes a simd extension called SPR (which is not IBM's cell SPE). Notably, it does not have altivec/fpr/vsx registers. It also has an SPE accumulator register which its ABI marks as volatile, but I am not sure if the compiler uses it.
Where supported, VSX is a 64x128b register set which encompasses
both the floating point and vector registers.
In the type tests, xvsqrtdp is used as it is the only two-argument
vsx opcode supported by all targets on llvm. If you need to copy
a vsx register, the preferred way is "xxlor xt, xa, xa".
Generalize configuring LLD as the default linker in bootstrap
Reopen of https://github.com/rust-lang/rust/pull/147157, because apparently bors can't deal with it for some reason.
r? ``@ghost``
Promote armv7a-none-eabihf to Tier 2
This PR promotes armv7a-none-eabihf to Tier 2, to join armv7r-none-eabihf and armv7a-none-eabi. I believe it was simply an oversight that it wasn't made Tier 2 before, as most Armv7-A targets have an FPU and it often makes sense to use it.
This PR wil be rebased once https://github.com/rust-lang/rust/pull/146419 completes the queue.
> - A tier 2 target must have value to people other than its maintainers. (It may
> still be a niche target, but it must not be exclusively useful for an
> inherently closed group.)
The `armv7a-none-eabihf` target is for all Arm Cortex-A processors (either 32-bit only, or in 32-bit mode) where the user wants to use the FPU.
>- A tier 2 target must have a designated team of developers (the "target
> maintainers") available to consult on target-specific build-breaking issues,
> or if necessary to develop target-specific language or library implementation
> details. This team must have at least 2 developers.
The Embedded Devices Working Group's Arm Team have just started maintaining this target.
> - The target must not place undue burden on Rust developers not specifically
> concerned with that target. Rust developers are expected to not gratuitously
> break a tier 2 target, but are not expected to become experts in every tier 2
> target, and are not expected to provide target-specific implementations for
> every tier 2 target.
This target is highly similar to a number of existing Tier 2 targets, including `armv7r-none-eabihf` and `armv7a-none-eabi` and so it should not add undue burden.
> - The target must provide documentation for the Rust community explaining how
> to build for the target using cross-compilation, and explaining how to run
> tests for the target. If at all possible, this documentation should show how
> to run Rust programs and tests for the target using emulation, to allow
> anyone to do so. If the target cannot be feasibly emulated, the documentation
> should explain how to obtain and work with physical hardware, cloud systems,
> or equivalent.
https://doc.rust-lang.org/nightly/rustc/platform-support/armv7a-none-eabi.html was added in https://github.com/rust-lang/rust/pull/146419/. It covers the `-eabi` and the `-eabihf` targets.
> - The target must document its baseline expectations for the features or
> versions of CPUs, operating systems, libraries, runtime environments, and
> similar.
I believe it does.
> - If introducing a new tier 2 or higher target that is identical to an existing
> Rust target except for the baseline expectations for the features or versions
> of CPUs, operating systems, libraries, runtime environments, and similar,
> then the proposed target must document to the satisfaction of the approving
> teams why the specific difference in baseline expectations provides
> sufficient value to justify a separate target.
It uses very similar FPUs to `armv7r-none-eabihf` but is otherwise the same as `armv7a-none-eabi`.
> - Tier 2 targets must not leave any significant portions of `core` or the
> standard library unimplemented or stubbed out, unless they cannot possibly be
> supported on the target.
It has a full libcore, as per the other arm*-none-* targets.
> - The code generation backend for the target should not have deficiencies that
> invalidate Rust safety properties, as evaluated by the Rust compiler team.
It should be the same backend as `armv7r-none-eabihf` and friends, except for FPU support, which is already covered in `thumbv8m.main-none-eabihf`. There are no issues that I know of.
> - If the target supports C code, and the target has an interoperable calling
> convention for C code, the Rust target must support that C calling convention
> for the platform via `extern "C"`. The C calling convention does not need to
> be the default Rust calling convention for the target, however.
The ABI is EABI, the same as many other Arm targets.
> - The target must build reliably in CI, for all components that Rust's CI
> considers mandatory.
The https://github.com/rust-embedded/cortex-ar repository has been changed in https://github.com/rust-embedded/cortex-ar/pull/57 to build this target with `-Zbuild-std=core`. Locally it seems fine.
> - The approving teams may additionally require that a subset of tests pass in
> CI, such as enough to build a functional "hello world" program, `./x.py test
> --no-run`, or equivalent "smoke tests". In particular, this requirement may
> apply if the target builds host tools, or if the tests in question provide
> substantial value via early detection of critical problems.
There are no no-std tests in the tree that I'm aware of.
> - Building the target in CI must not take substantially longer than the current
> slowest target in CI, and should not substantially raise the maintenance
> burden of the CI infrastructure. This requirement is subjective, to be
> evaluated by the infrastructure team, and will take the community importance
> of the target into account.
Building libcore is quite fast.
> - Tier 2 targets should, if at all possible, support cross-compiling. Tier 2
> targets should not require using the target as the host for builds, even if
> the target supports host tools.
It does.
> - In addition to the legal requirements for all targets (specified in the tier
> 3 requirements), because a tier 2 target typically involves the Rust project
> building and supplying various compiled binaries, incorporating the target
> and redistributing any resulting compiled binaries (e.g. built libraries,
> host tools if any) must not impose any onerous license requirements on any
> members of the Rust project, including infrastructure team members and those
> operating CI systems. This is a subjective requirement, to be evaluated by
> the approving teams.
Just libcore required (and liballoc). No known issues here.
> - Tier 2 targets must not impose burden on the authors of pull requests, or
> other developers in the community, to ensure that tests pass for the target.
Noted
> - The target maintainers should regularly run the testsuite for the target
The https://github.com/rust-embedded/cortex-ar repository will be changed to use the rustup component when available.
> and should fix any test failures in a reasonably timely fashion.
Noted
Promote armv8r-none-eabihf target to Tier 2
This PR promotes armv8r-none-eabihf to Tier 2, joining armv7r-none-eabi, armv7r-none-eabihf and armv7a-none-eabi.
This PR wil be rebased once https://github.com/rust-lang/rust/pull/146419 completes the queue.
> - A tier 2 target must have value to people other than its maintainers. (It may
> still be a niche target, but it must not be exclusively useful for an
> inherently closed group.)
The `armv8r-none-eabihf` target is for the Arm Cortex-R52 processor, as found in a number of Automotive SoCs that have just been released, or are about to be released. Currently SoCs are available from NXP and Renesas.
>- A tier 2 target must have a designated team of developers (the "target
> maintainers") available to consult on target-specific build-breaking issues,
> or if necessary to develop target-specific language or library implementation
> details. This team must have at least 2 developers.
The Embedded Devices Working Group's Arm Team have just started maintaining this target.
> - The target must not place undue burden on Rust developers not specifically
> concerned with that target. Rust developers are expected to not gratuitously
> break a tier 2 target, but are not expected to become experts in every tier 2
> target, and are not expected to provide target-specific implementations for
> every tier 2 target.
This target is highly similar to a number of existing Tier 2 targets, including `armv7r-none-eabihf` and so it should not add undue burden.
> - The target must provide documentation for the Rust community explaining how
> to build for the target using cross-compilation, and explaining how to run
> tests for the target. If at all possible, this documentation should show how
> to run Rust programs and tests for the target using emulation, to allow
> anyone to do so. If the target cannot be feasibly emulated, the documentation
> should explain how to obtain and work with physical hardware, cloud systems,
> or equivalent.
https://doc.rust-lang.org/nightly/rustc/platform-support/armv8r-none-eabihf.html exists and was updated in https://github.com/rust-lang/rust/pull/146419/
> - The target must document its baseline expectations for the features or
> versions of CPUs, operating systems, libraries, runtime environments, and
> similar.
I believe it does.
> - If introducing a new tier 2 or higher target that is identical to an existing
> Rust target except for the baseline expectations for the features or versions
> of CPUs, operating systems, libraries, runtime environments, and similar,
> then the proposed target must document to the satisfaction of the approving
> teams why the specific difference in baseline expectations provides
> sufficient value to justify a separate target.
The Armv8-R architecture introduces a new FPU type, the fp-armv8, and so this requires a unique target.
> - Tier 2 targets must not leave any significant portions of `core` or the
> standard library unimplemented or stubbed out, unless they cannot possibly be
> supported on the target.
It has a full libcore, as per the other arm*-none-* targets.
> - The code generation backend for the target should not have deficiencies that
> invalidate Rust safety properties, as evaluated by the Rust compiler team.
It should be the same backend as `armv7r-none-eabihf` and friends, except for FPU support, which is already covered in `thumbv8m.main-none-eabihf`. There are no issues that I know of.
> - If the target supports C code, and the target has an interoperable calling
> convention for C code, the Rust target must support that C calling convention
> for the platform via `extern "C"`. The C calling convention does not need to
> be the default Rust calling convention for the target, however.
The ABI is EABI, the same as many other Arm targets.
> - The target must build reliably in CI, for all components that Rust's CI
> considers mandatory.
The https://github.com/rust-embedded/cortex-ar repository regularly builds this target with `-Zbuild-std=core` and it seems fine.
> - The approving teams may additionally require that a subset of tests pass in
> CI, such as enough to build a functional "hello world" program, `./x.py test
> --no-run`, or equivalent "smoke tests". In particular, this requirement may
> apply if the target builds host tools, or if the tests in question provide
> substantial value via early detection of critical problems.
There are no no-std tests in the tree that I'm aware of.
> - Building the target in CI must not take substantially longer than the current
> slowest target in CI, and should not substantially raise the maintenance
> burden of the CI infrastructure. This requirement is subjective, to be
> evaluated by the infrastructure team, and will take the community importance
> of the target into account.
Building libcore is quite fast.
> - Tier 2 targets should, if at all possible, support cross-compiling. Tier 2
> targets should not require using the target as the host for builds, even if
> the target supports host tools.
It does.
> - In addition to the legal requirements for all targets (specified in the tier
> 3 requirements), because a tier 2 target typically involves the Rust project
> building and supplying various compiled binaries, incorporating the target
> and redistributing any resulting compiled binaries (e.g. built libraries,
> host tools if any) must not impose any onerous license requirements on any
> members of the Rust project, including infrastructure team members and those
> operating CI systems. This is a subjective requirement, to be evaluated by
> the approving teams.
Just libcore required (and liballoc). No known issues here.
> - Tier 2 targets must not impose burden on the authors of pull requests, or
> other developers in the community, to ensure that tests pass for the target.
Noted
> - The target maintainers should regularly run the testsuite for the target
The https://github.com/rust-embedded/cortex-ar repository will be changed to use the rustup component when available.
> and should fix any test failures in a reasonably timely fashion.
Noted
Set the minimum deployment target for `aarch64-apple-watchos`
To match what's done in LLVM 21 and Xcode 26, watchOS 26 is the first OS version that actually runs true Aarch64 binaries. This affects the object files we create, and the linker invocation when using `-Clinker=ld`.
See also investigation in https://github.com/rust-lang/rust/issues/147223.
Add a new `wasm32-wasip3` target to Rust
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target.
These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
This will make `-Zbuild-std` automatically build the right crates, notably not building `std` by default, which will both be useful for users and also fix the build for https://does-it-build.noratrieb.dev.
Fix backtraces with `-C panic=abort` on linux; emit unwind tables by default
The linux backtrace unwinder relies on unwind tables to work properly, and generating and printing a backtrace is done by for example the default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see history below) so that backtraces work.
Closes https://github.com/rust-lang/rust/issues/81902 which is **regression-from-stable-to-stable**
Closes https://github.com/rust-lang/rust/issues/94815
### History
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C panic=abort` (see https://github.com/rust-lang/rust/pull/45031 and https://github.com/rust-lang/rust/issues/81902#issuecomment-3046487084).
In 1.45 a workaround in the form of `-C force-unwind-tables=yes` was added (see https://github.com/rust-lang/rust/pull/69984).
`-C panic=abort` was added in [Rust 1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable) and the motivation was binary size and compile time. But given how confusing that behavior has turned out to be, it is better to make binary size optimization opt-in with `-C force-unwind-tables=no` rather than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other tricks that can be used that has a higher impact.
# Release Note Entry Draft:
## Compatibility Notes
* [Fix backtraces with `-C panic=abort` on Linux by generating unwind tables by default](https://github.com/rust-lang/rust/pull/143613). Build with `-C force-unwind-tables=no` to keep omitting unwind tables.
try-job: aarch64-apple
try-job: armhf-gnu
try-job: aarch64-msvc-1
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This
follows in the footsteps of the previous `wasm32-wasip2` target and is
used to represent binding to the WASIp3 set of APIs managed by the WASI
subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized.
They're in the process of doing so and the current trajectory is to have
the APIs published in December of this year. The goal here is to get the
wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as
`wasm32-wasip2` except that `target_env = "p3"` is specified. This
indicates to crates in the ecosystem that WASIp3 APIs should be used,
such as the [`wasip3` crate]. Over time this target will evolve as
implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're
finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively
which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added
to the WASIp3-track of targets to enable using `std::thread`, for
example, on this target.
These changes are all expected to be non-breaking changes for users of
this target. Runtimes supporting WASIp3, currently Wasmtime and Jco,
support WASIp2 APIs as well and will work with components whether or not
they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This
means that changing the internal implementation details of libstd over
time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
The linux backtrace unwinder relies on unwind tables to work properly,
and generating and printing a backtrace is done by for example the
default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see
history below) so that backtraces work.
History
=======
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in
Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C
panic=abort` (see 24cc38e3b0).
In 1.45 (see cda994633e) a workaround in the form
of `-C force-unwind-tables=yes` was added.
`-C panic=abort` was added in [Rust
1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable)
and the motivation was binary size and compile time. But given how
confusing that behavior has turned out to be, it is better to make
binary size optimization opt-in with `-C force-unwind-tables=no` rather
than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other
tricks that can be used that has a higher impact.
Improve the documentation around `ZERO_AR_DATE`
In particular, document why we don't use the new `-reproducible` flag.
I went through [the source for Apple's old linker](https://github.com/apple-oss-distributions/ld64), and compared the versions with [the mapping to Xcode versions on Wikipedia](https://en.wikipedia.org/wiki/Xcode) to find the relevant Xcode versions for these features.
r? compiler
remove explicit deref of AbiAlign for most methods
Much of the compiler calls functions on Align projected from AbiAlign. AbiAlign impls Deref to its inner Align, so we can simplify these away. Also, it will minimize disruption when AbiAlign is removed.
For now, preserve usages that might resolve to PartialOrd or PartialEq, as those have odd inference.
Much of the compiler calls functions on Align projected from AbiAlign.
AbiAlign impls Deref to its inner Align, so we can simplify these away.
Also, it will minimize disruption when AbiAlign is removed.
For now, preserve usages that might resolve to PartialOrd or PartialEq,
as those have odd inference.
Stop linking rs{begin,end} objects on x86_64-*-windows-gnu
Until now, x86_64-pc-windows-gnu linked `rsbegin.o` and `rsend.o` just like i686-pc-windows-gnu, even though they were no-ops for it. This was likely done for the simplicity back when it was introduced.
Today the things are different and these startup/end objects harm other features, like `build-std`. Given the demotion of i686-pc-windows-gnu from tier 1, there is no point in hurting x86_64-pc-windows-gnu, which remains a tier 1.
The files are still shipped in case downstream crates expect them, as in case of the unmaintained `xargo`.
Fixes https://github.com/rust-lang/rust/issues/146739
Demote both armebv7r-none-* targets.
OK, slightly more controversial than https://github.com/rust-lang/rust/pull/146520 and https://github.com/rust-lang/rust/pull/146522 - I'd like to drop the bare-metal **big-endian** Armv7-R targets down to Tier 3.
The reason is simple - we cannot test them in https://github.com/rust-embedded/cortex-ar/. This because QEMU support for Big Endian Armv7-R is broken. I tried quite hard, but all the strings I printed with semihosting came out byte swapped (or "etybawa depp") because of how QEMU kludges the access to memory in big-endian mode.
The target also has only a single maintainer. Although, if ````@chrisnc```` wants to put up a case for keeping it at Tier 2 though, I'm happy to hear it!
This PR wil be rebased once https://github.com/rust-lang/rust/pull/146419 completes the queue.
Add `std` support for `armv7a-vex-v5`
This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). It is more-or-less an updated version of the library-side work done in rust-lang/rust#131530.
This was a joint effort between me, `@lewisfm,` `@max-niederman,` `@Gavin-Niederman` and several other members of the [`vexide` project](https://github.com/vexide/).
## Background
VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as `std::net`, `std::process`, and most of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see [this comment](https://github.com/rust-lang/rust/pull/131530#issuecomment-2432856841).
## SDK Linkage
VEXos doesn't really ship with an official `libc` or POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of the `armv6k-nintendo-3ds` team's work in rust-lang/rust#95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options:
- [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script.
- [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps.
- [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions.
- Linking their own implementation or stubbing the functions required by libstd.
The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main).
## Future Work
This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently [gross enough](c6c5bad11e/packages/vexide-core/src/fs/mod.rs (L987)) to drive us away from supporting this officially.
Additionally, I have a working branch implementing the `panic_unwind` runtime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.
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.
Add x86_64-unknown-motor (Motor OS) tier 3 target
Add the initial no-std Motor OS compiler target.
Motor OS has been developed for several years in the open: https://github.com/moturus/motor-os.
It has a more or less full implementation of Rust std library, as well as tokio/mio ports.
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
Ack. [U. Lasiotus](https://github.com/lasiotus) will maintain the target.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
> If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo.
Ack. The new target is named `x86_64-unknown-motor`, as it represents Motor OS on x86_64.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
> The target must not introduce license incompatibilities.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
Ack. Motor OS is dual-licensed under MIT and/or Apache-2.0.
> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
Ack.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
Motor OS has a functional implementation of the standard library: https://github.com/moturus/rust/tree/motor-os_stdlib, which will be the subject of a later PR.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
Building instructions for Motor OS: https://github.com/moturus/motor-os/blob/main/docs/build.md.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
Ack.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
Ack.
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)
Motor OS uses the standard x86_64 rustc/llvm toolchain.
> If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.
Ack.
Enable `limit_rdylib_exports` on wasm targets
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.
Make mips64el-unknown-linux-muslabi64 link dynamically
I missed this target when I changed all the other tier 3 targets in https://github.com/rust-lang/rust/pull/144410. Only realized that this one was still statically linked when I looked at the list of targets in the test later (https://github.com/rust-lang/rust/pull/146588).
since those two PRs were reviewed by you:
r? ````@jieyouxu````
I missed this target when I changed all the other tier 3 targets. Only
realized that this one was still statically linked when I looked at the
list of targets in the test later.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
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.
Until now, x86_64-pc-windows-gnu linked `rsbegin.o` and `rsend.o` just
like i686-pc-windows-gnu, even though they were no-ops for it.
This was likely done for the simplicity back when it was introduced.
Today the things are different and these startup/end objects harm other
features, like `build-std`. Given the demotion of i686-pc-windows-gnu
from tier 1, there is no point in hurting x86_64-pc-windows-gnu,
which remains a tier 1.
The files are still shipped in case downstream crates expect them, as in
case of the unmaintained `xargo`.
This is the target for 32-bit Cortex-A bare-metal, when using the FPU.
The target is well tested by the Embedded Devices Working Group, and the
soft-float target (armv7a-none-eabi) is already Tier 2.
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.
With this macro we only need to enumerate every variant once. This saves
a lot of duplication already between the definition, the `FromStr` impl
and the `ToJson` impl.
It also enables us to do further things with it like JSON schema
generation.
