Adds two new Tier 3 targets - aarch64v8r-unknown-none{,-softfloat}
#150863
Conversation
|
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. |
rustbot
added
PG-exploit-mitigations
jonathanpallant
force-pushed
the
add-aarch64v8r-targets
branch
from
24ef519 to
61919a8
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Ah, we've accidentally made |
|
r? @wesleywiser |
This comment has been minimized.
This comment has been minimized.
| stack_probes: StackProbeType::Inline, | ||
| panic_strategy: PanicStrategy::Abort, | ||
| default_uwtable: true, | ||
|
|
There was a problem hiding this comment.
Given the discussion around #149622, I wonder if these targets should be added with
| position_independent_executables: true, | |
| static_position_independent_executables: true, | |
since the consensus seemed to be that it would make sense for our existing aarch64 targets to be configured that way except it could break people already using the targets.
There was a problem hiding this comment.
We tried that and things broke (IIRC), so we wanted to (or you to) fix all the breakages in the existing target before we flipped that switch.
There was a problem hiding this comment.
We tried that and things broke (IIRC),
On this specfic point, as far as I could test the patch in #149622 breaks existing aarch64-unknown-none code that uses the aarch64-rt and/or the semihosting crate. This can be observed in this example: QEMU hangs and no output is printed; but the behavior can be observed in simpler programs as well.
As the AArch64 v8-R ISA builds on top of the Armv8.4-A ISA taking that patch has the same effect on this target.
There was a problem hiding this comment.
I don't currently have cycles to drive that work so I don't want to block this on it.
jonathanpallant
force-pushed
the
add-aarch64v8r-targets
branch
from
3a967cb to
26db97d
Compare
|
There are comments above about "should this target include the changes in #149622". Reasons we should do this
Reasons we should not do this
My ProposalWe 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 |
…n-none-softfloat This change adds testing of upstream targets named above. It should be applied after rust-lang/rust#150863 is merged upstream and pulled down via PR rotation. The aarch64v8r-unknown-none target should be offered at the Supported Targets tier, because it is qualification ready and has been observed to pass the qualification test suite. The aarch64v8r-unknown-none-softfloat target should be offered at the Experimental Targets tier, because it is not qualification ready and the test suite is not currently executable for this target due to incompatibilities between the soft-float ABI and our test running library. This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
This PR adds checks to the `aarch64v8r-unknown-none` target to verify that if the Cortex-R82 CPU is enabled (with `-Ctarget-cpu=cortex-r82`), that the appropriate additional AArch64 features are enabled. This is important because Cortex-R82 is (currently) the only processor implementing Armv8-R AArch64 and it implements a number of Armv8 features over and above the baseline for the architecture. Many of these features are of interest to safety-critical firmware development (for example `FEAT_RASv1p1`, which adds support for the *RAS Common Fault Injection Model Extension*) and so we anticipate them being enabled when building such firmware. We are offering these tests upstream in-lieu of a full Cortex-R82 specific target because we understand the Project has a preference for architecture-baseline targets over CPU-specific targets. This PR builds on and requires rust-lang#150863, but we've pulled them out as a separate PR. This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
…n-none-softfloat This change adds testing of upstream targets named above. It should be applied after rust-lang/rust#150863 is merged upstream and pulled down via PR rotation. The aarch64v8r-unknown-none target should be offered at the Supported Targets tier, because it is qualification ready and has been observed to pass the qualification test suite. The aarch64v8r-unknown-none-softfloat target should be offered at the Experimental Targets tier, because it is not qualification ready and the test suite is not currently executable for this target due to incompatibilities between the soft-float ABI and our test running library. This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
This comment has been minimized.
This comment has been minimized.
|
The EDWG consented to maintainership in rust-embedded/wg#892. |
jonathanpallant
force-pushed
the
add-aarch64v8r-targets
branch
from
26db97d to
3eefca1
Compare
|
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. |
This PR adds checks to the `aarch64v8r-unknown-none` target to verify that if the Cortex-R82 CPU is enabled (with `-Ctarget-cpu=cortex-r82`), that the appropriate additional AArch64 features are enabled. This is important because Cortex-R82 is (currently) the only processor implementing Armv8-R AArch64 and it implements a number of Armv8 features over and above the baseline for the architecture. Many of these features are of interest to safety-critical firmware development (for example `FEAT_RASv1p1`, which adds support for the *RAS Common Fault Injection Model Extension*) and so we anticipate them being enabled when building such firmware. We are offering these tests upstream in-lieu of a full Cortex-R82 specific target because we understand the Project has a preference for architecture-baseline targets over CPU-specific targets. This PR builds on and requires rust-lang#150863, but we've pulled them out as a separate PR. This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
…8r-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. This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
japaric
force-pushed
the
add-aarch64v8r-targets
branch
from
3eefca1 to
5cf807e
Compare
|
@wesleywiser commits have been squashed |
This PR adds checks to the `aarch64v8r-unknown-none` target to verify that if the Cortex-R82 CPU is enabled (with `-Ctarget-cpu=cortex-r82`), that the appropriate additional AArch64 features are enabled. This is important because Cortex-R82 is (currently) the only processor implementing Armv8-R AArch64 and it implements a number of Armv8 features over and above the baseline for the architecture. Many of these features are of interest to safety-critical firmware development (for example `FEAT_RASv1p1`, which adds support for the *RAS Common Fault Injection Model Extension*) and so we anticipate them being enabled when building such firmware. We are offering these tests upstream in-lieu of a full Cortex-R82 specific target because we understand the Project has a preference for architecture-baseline targets over CPU-specific targets. This PR builds on and requires rust-lang#150863, but we've pulled them out as a separate PR. This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
8 participants
New Tier 3 targets -
aarch64v8r-unknown-noneandaarch64v8r-unknown-none-softfloatThis PR adds two new Tier 3 targets -
aarch64v8r-unknown-noneandaarch64v8r-unknown-none-softfloat.The existing
aarch64-unknown-nonetarget 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-softfloattarget allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existingaarch64-unknown-nonetarget 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-noneto 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:
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.
We prefix this target with
aarch64because it generates A64 machine code (likearm*generates A32 andthumb*generates T32). In an ideal world I'd get to rename the existing targetaarch64v8a-unknown-nonebut that's basically impossible at this point. You can assumev6for anyarm*target where unspecified, and you can assumev8afor anyaarch64*target where not specified.It works just like the existing AArch64 bare-metal target.
Noted.
It's a bare-metal target, offering libcore and liballoc.
Done
AArch64 is a Tier 1 architecture, so I don't expect this target to cause any issues.
Noted.
It's AArch64 and so works with LLVM.