Auto merge of #114004 - hermitcore:riscv64gc-unknown-hermit, r=davidtwco
Add `riscv64gc-unknown-hermit` target This PR adds the new `riscv64gc-unknown-hermit` target, initially created by `@simonschoening,` a 64-bit RISC-V target for the [Hermit] unikernel project. Furthermore, this cleans up the existing Hermit targets and adds a platform support documentation page for _all_ Hermit targets and goes through the new tier 3 target policy process: [Hermit]: https://github.com/hermitcore ## Tier 3 target policy > - 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.) `@stlankes` as the Hermit project lead and I will be the target maintainers. > - 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. The target name `riscv64gc-unknown-hermit` was derived from the existing `x86_64-unknown-hermit` and `aarch64-unknown-hermit` targets. > - 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. > - 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. No dependencies were added to Rust. > - 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. Understood. I am not a member of a Rust team. > - 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. Understood. `std` is supported. > - 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 is described in the platform support doc. > - 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. > - 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. Understood. > - 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. I don't think this PR breaks anything. r? compiler-team
This commit is contained in:
bors
commit
48c0c25395
@ -1,15 +1,15 @@
|
||||
use crate::spec::Target;
|
||||
use crate::spec::{Target, TargetOptions};
|
||||
|
||||
pub fn target() -> Target {
|
||||
let mut base = super::hermit_base::opts();
|
||||
base.max_atomic_width = Some(128);
|
||||
base.features = "+v8a,+strict-align,+neon,+fp-armv8".into();
|
||||
|
||||
Target {
|
||||
llvm_target: "aarch64-unknown-hermit".into(),
|
||||
pointer_width: 64,
|
||||
data_layout: "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128".into(),
|
||||
arch: "aarch64".into(),
|
||||
options: base,
|
||||
data_layout: "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128".into(),
|
||||
options: TargetOptions {
|
||||
features: "+v8a,+strict-align,+neon,+fp-armv8".into(),
|
||||
max_atomic_width: Some(128),
|
||||
..super::hermit_base::opts()
|
||||
},
|
||||
}
|
||||
}
|
||||
|
||||
@ -1,21 +1,15 @@
|
||||
use crate::spec::{Cc, LinkerFlavor, Lld, PanicStrategy, TargetOptions, TlsModel};
|
||||
|
||||
pub fn opts() -> TargetOptions {
|
||||
let pre_link_args = TargetOptions::link_args(
|
||||
LinkerFlavor::Gnu(Cc::No, Lld::No),
|
||||
&["--build-id", "--hash-style=gnu", "--Bstatic"],
|
||||
);
|
||||
|
||||
TargetOptions {
|
||||
os: "hermit".into(),
|
||||
linker_flavor: LinkerFlavor::Gnu(Cc::No, Lld::Yes),
|
||||
linker: Some("rust-lld".into()),
|
||||
has_thread_local: true,
|
||||
pre_link_args,
|
||||
panic_strategy: PanicStrategy::Abort,
|
||||
linker_flavor: LinkerFlavor::Gnu(Cc::No, Lld::Yes),
|
||||
tls_model: TlsModel::InitialExec,
|
||||
position_independent_executables: true,
|
||||
static_position_independent_executables: true,
|
||||
tls_model: TlsModel::InitialExec,
|
||||
has_thread_local: true,
|
||||
panic_strategy: PanicStrategy::Abort,
|
||||
..Default::default()
|
||||
}
|
||||
}
|
||||
|
||||
@ -1418,6 +1418,7 @@ fn $module() {
|
||||
("msp430-none-elf", msp430_none_elf),
|
||||
|
||||
("aarch64-unknown-hermit", aarch64_unknown_hermit),
|
||||
("riscv64gc-unknown-hermit", riscv64gc_unknown_hermit),
|
||||
("x86_64-unknown-hermit", x86_64_unknown_hermit),
|
||||
|
||||
("riscv32i-unknown-none-elf", riscv32i_unknown_none_elf),
|
||||
|
||||
20
compiler/rustc_target/src/spec/riscv64gc_unknown_hermit.rs
Normal file
20
compiler/rustc_target/src/spec/riscv64gc_unknown_hermit.rs
Normal file
@ -0,0 +1,20 @@
|
||||
use crate::spec::{CodeModel, RelocModel, Target, TargetOptions, TlsModel};
|
||||
|
||||
pub fn target() -> Target {
|
||||
Target {
|
||||
llvm_target: "riscv64-unknown-hermit".into(),
|
||||
pointer_width: 64,
|
||||
arch: "riscv64".into(),
|
||||
data_layout: "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128".into(),
|
||||
options: TargetOptions {
|
||||
cpu: "generic-rv64".into(),
|
||||
features: "+m,+a,+f,+d,+c".into(),
|
||||
relocation_model: RelocModel::Pic,
|
||||
code_model: Some(CodeModel::Medium),
|
||||
tls_model: TlsModel::LocalExec,
|
||||
max_atomic_width: Some(64),
|
||||
llvm_abiname: "lp64d".into(),
|
||||
..super::hermit_base::opts()
|
||||
},
|
||||
}
|
||||
}
|
||||
@ -1,19 +1,19 @@
|
||||
use crate::spec::{StackProbeType, Target};
|
||||
use crate::spec::{StackProbeType, Target, TargetOptions};
|
||||
|
||||
pub fn target() -> Target {
|
||||
let mut base = super::hermit_base::opts();
|
||||
base.cpu = "x86-64".into();
|
||||
base.plt_by_default = false;
|
||||
base.max_atomic_width = Some(64);
|
||||
base.features = "+rdrnd,+rdseed".into();
|
||||
base.stack_probes = StackProbeType::X86;
|
||||
|
||||
Target {
|
||||
llvm_target: "x86_64-unknown-hermit".into(),
|
||||
pointer_width: 64,
|
||||
arch: "x86_64".into(),
|
||||
data_layout: "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
|
||||
.into(),
|
||||
arch: "x86_64".into(),
|
||||
options: base,
|
||||
options: TargetOptions {
|
||||
cpu: "x86-64".into(),
|
||||
features: "+rdrnd,+rdseed".into(),
|
||||
plt_by_default: false,
|
||||
max_atomic_width: Some(64),
|
||||
stack_probes: StackProbeType::X86,
|
||||
..super::hermit_base::opts()
|
||||
},
|
||||
}
|
||||
}
|
||||
|
||||
@ -42,6 +42,7 @@
|
||||
- [sparc-unknown-none-elf](./platform-support/sparc-unknown-none-elf.md)
|
||||
- [*-pc-windows-gnullvm](platform-support/pc-windows-gnullvm.md)
|
||||
- [\*-nto-qnx-\*](platform-support/nto-qnx.md)
|
||||
- [*-unknown-hermit](platform-support/hermit.md)
|
||||
- [\*-unknown-netbsd\*](platform-support/netbsd.md)
|
||||
- [*-unknown-openbsd](platform-support/openbsd.md)
|
||||
- [\*-unknown-uefi](platform-support/unknown-uefi.md)
|
||||
|
||||
@ -223,7 +223,7 @@ target | std | host | notes
|
||||
[`aarch64-unknown-linux-ohos`](platform-support/openharmony.md) | ✓ | | ARM64 OpenHarmony |
|
||||
[`aarch64-unknown-nto-qnx710`](platform-support/nto-qnx.md) | ✓ | | ARM64 QNX Neutrino 7.1 RTOS |
|
||||
`aarch64-unknown-freebsd` | ✓ | ✓ | ARM64 FreeBSD
|
||||
`aarch64-unknown-hermit` | ✓ | | ARM64 HermitCore
|
||||
[`aarch64-unknown-hermit`](platform-support/hermit.md) | ✓ | | ARM64 Hermit
|
||||
`aarch64-unknown-linux-gnu_ilp32` | ✓ | ✓ | ARM64 Linux (ILP32 ABI)
|
||||
[`aarch64-unknown-netbsd`](platform-support/netbsd.md) | ✓ | ✓ | ARM64 NetBSD
|
||||
[`aarch64-unknown-openbsd`](platform-support/openbsd.md) | ✓ | ✓ | ARM64 OpenBSD
|
||||
@ -303,6 +303,7 @@ target | std | host | notes
|
||||
[`riscv32imac-unknown-xous-elf`](platform-support/riscv32imac-unknown-xous-elf.md) | ? | | RISC-V Xous (RV32IMAC ISA)
|
||||
[`riscv32imc-esp-espidf`](platform-support/esp-idf.md) | ✓ | | RISC-V ESP-IDF
|
||||
[`riscv32imac-esp-espidf`](platform-support/esp-idf.md) | ✓ | | RISC-V ESP-IDF
|
||||
[`riscv64gc-unknown-hermit`](platform-support/hermit.md) | ✓ | | RISC-V Hermit
|
||||
`riscv64gc-unknown-freebsd` | | | RISC-V FreeBSD
|
||||
`riscv64gc-unknown-fuchsia` | | | RISC-V Fuchsia
|
||||
`riscv64gc-unknown-linux-musl` | | | RISC-V Linux (kernel 4.20, musl 1.2.0)
|
||||
@ -327,7 +328,7 @@ target | std | host | notes
|
||||
`x86_64-sun-solaris` | ? | | Deprecated target for 64-bit Solaris 10/11, illumos
|
||||
`x86_64-unknown-dragonfly` | ✓ | ✓ | 64-bit DragonFlyBSD
|
||||
`x86_64-unknown-haiku` | ✓ | ✓ | 64-bit Haiku
|
||||
`x86_64-unknown-hermit` | ✓ | | HermitCore
|
||||
[`x86_64-unknown-hermit`](platform-support/hermit.md) | ✓ | | x86_64 Hermit
|
||||
`x86_64-unknown-l4re-uclibc` | ? | |
|
||||
[`x86_64-unknown-linux-ohos`](platform-support/openharmony.md) | ✓ | | x86_64 OpenHarmony |
|
||||
[`x86_64-unknown-openbsd`](platform-support/openbsd.md) | ✓ | ✓ | 64-bit OpenBSD
|
||||
|
||||
75
src/doc/rustc/src/platform-support/hermit.md
Normal file
75
src/doc/rustc/src/platform-support/hermit.md
Normal file
@ -0,0 +1,75 @@
|
||||
# `*-unknown-hermit`
|
||||
|
||||
**Tier: 3**
|
||||
|
||||
The [Hermit] unikernel target allows compiling your applications into self-contained, specialized unikernel images that can be run in small virtual machines.
|
||||
|
||||
[Hermit]: https://github.com/hermitcore
|
||||
|
||||
Target triplets available so far:
|
||||
|
||||
- `x86_64-unknown-hermit`
|
||||
- `aarch64-unknown-hermit`
|
||||
- `riscv64gc-unknown-hermit`
|
||||
|
||||
## Target maintainers
|
||||
|
||||
- Stefan Lankes ([@stlankes](https://github.com/stlankes))
|
||||
- Martin Kröning ([@mkroening](https://github.com/mkroening))
|
||||
|
||||
## Requirements
|
||||
|
||||
These targets only support cross-compilation.
|
||||
The targets do support std.
|
||||
|
||||
When building binaries for this target, the Hermit unikernel is built from scratch.
|
||||
The application developer themselves specializes the target and sets corresponding expectations.
|
||||
|
||||
The Hermit targets follow Linux's `extern "C"` calling convention.
|
||||
|
||||
Hermit binaries have the ELF format.
|
||||
|
||||
## Building the target
|
||||
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `config.toml`.
|
||||
To run the Hermit build scripts, you also have to enable your host target.
|
||||
The build scripts rely on `llvm-tools` and binaries are linked using `rust-lld`, so those have to be enabled as well.
|
||||
|
||||
```toml
|
||||
[build]
|
||||
build-stage = 1
|
||||
target = [
|
||||
"<HOST_TARGET>",
|
||||
"x86_64-unknown-hermit",
|
||||
"aarch64-unknown-hermit",
|
||||
"riscv64gc-unknown-hermit",
|
||||
]
|
||||
|
||||
[rust]
|
||||
lld = true
|
||||
llvm-tools = true
|
||||
```
|
||||
|
||||
## Building Rust programs
|
||||
|
||||
Rust does not yet ship pre-compiled artifacts for these targets.
|
||||
To compile for these targets, you will either need to build Rust with the targets enabled
|
||||
(see “Building the targets” above), or build your own copy of `core` by using `build-std` or similar.
|
||||
|
||||
Building Rust programs can be done by following the tutorial in our starter application [rusty-demo].
|
||||
|
||||
[rusty-demo]: https://github.com/hermitcore/rusty-demo
|
||||
|
||||
## Testing
|
||||
|
||||
The targets support running binaries in the form of self-contained unikernel images.
|
||||
These images can be chainloaded by Hermit's [loader] or hypervisor ([Uhyve]).
|
||||
QEMU can be used to boot Hermit binaries using the loader on any architecture.
|
||||
The targets do not support running the Rust test suite.
|
||||
|
||||
[loader]: https://github.com/hermitcore/rusty-loader
|
||||
[Uhyve]: https://github.com/hermitcore/uhyve
|
||||
|
||||
## Cross-compilation toolchains and C code
|
||||
|
||||
The targets do not yet support C code and Rust code at the same time.
|
||||
@ -122,6 +122,7 @@
|
||||
"riscv32imac-unknown-none-elf",
|
||||
"riscv32gc-unknown-linux-gnu",
|
||||
"riscv64imac-unknown-none-elf",
|
||||
"riscv64gc-unknown-hermit",
|
||||
"riscv64gc-unknown-none-elf",
|
||||
"riscv64gc-unknown-linux-gnu",
|
||||
"s390x-unknown-linux-gnu",
|
||||
|
||||
Loading…
Reference in New Issue
Block a user