Adds two new Tier 3 targets - aarch64v8r-unknown-none{,-softfloat}

[jonathanpallant]

New Tier 3 targets - aarch64v8r-unknown-none and aarch64v8r-unknown-none-softfloat

This PR adds two new Tier 3 targets - aarch64v8r-unknown-none and aarch64v8r-unknown-none-softfloat.

The existing aarch64-unknown-none target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (armv8r-none-eabihf), which only operates in AArch32 mode.

The second aarch64v8r-unknown-none-softfloat target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing aarch64-unknown-none target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it.

These targets are in support of firmware development on upcoming systems using the Arm Cortex-R82, particularly safety-critical firmware development. For now, it can be tested using the Arm's Armv8-R AArch64 Fixed Virtual Platform emulator, which we have used to test this target. We are also in the process of testing this target with the full compiler test suite as part of Ferrocene, in the same way we test aarch64-unknown-none to a safety-qualified standard. We have not identified any issues as yet, but if we do, we will send the fixes upstream to you.

Ownership

This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.

Tier 3 Policy Notes

To cover off the Tier 3 requirements:

A tier 3 target must have a designated developer or developers

Arm will maintain this target, and I have presumed the Embedded Devices Working Group will also take an interest, as they maintain the existing Arm bare-metal targets.

Targets must use naming consistent with any existing targets

We prefix this target with aarch64 because it generates A64 machine code (like arm* generates A32 and thumb* generates T32). In an ideal world I'd get to rename the existing target aarch64v8a-unknown-none but that's basically impossible at this point. You can assume v6 for any arm* target where unspecified, and you can assume v8a for any aarch64* target where not specified.

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.

It works just like the existing AArch64 bare-metal target.

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.

Noted.

Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate.

It's a bare-metal target, offering libcore and liballoc.

The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.

Done

Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target.

AArch64 is a Tier 1 architecture, so I don't expect this target to cause any issues.

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.

Noted.

Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.

It's AArch64 and so works with LLVM.

[rustbot]

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

Some changes occurred in tests/codegen-llvm/sanitizer

cc @rcvalle

These commits modify compiler targets.
(See the Target Tier Policy.)

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jonathanpallant]

Ah, we've accidentally made tidy sad. Pinging @japaric to take a look at those failures.

[davidtwco]

r? @wesleywiser

[jonathanpallant]

There are comments above about "should this target include the changes in #149622".

Reasons we should do this

• We wouldn't have to change this target later when #149622 merges, potentially causing breakage.

Reasons we should not do this

• Those changes may require changes in third-party crates (e.g. aarch64-rt)
• Applying those changes here when #149622 isn't merged would mean that two similar AArch64 bare-metal targets operate quite differently, which might cause confusion

My Proposal

We merge this target as-is, and we adjust #149622 to also patch these target, keeping them in sync. We can then work out what third-party crate changes are required and fix all four targets at the same time. The downside that this target would be static initially and change to be relocatable later will affect only a small number of people, and as the target is Tier 3 it can be subject to these kinds of changes anyway. Whatever announcements are made for the aarch64-unknown-none target when it changes can also just mention this target.

[jonathanpallant]

The EDWG consented to maintainership in rust-embedded/wg#892.

[rust-bors]

@japaric: 🔑 Insufficient privileges: not in review users

[jonathanpallant]

@bors r=wesleywiser

[rust-bors]

@jonathanpallant: 🔑 Insufficient privileges: not in review users

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jonathanpallant]

Sorry, the rebase undid the squash. Now squashed again.

[wesleywiser]

@bors r+ rollup

[rust-bors]

📌 Commit 6ecb3f3 has been approved by wesleywiser

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.