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
e1af13b7c0