Auto merge of rust-lang#114004 - hermitcore:riscv64gc-unknown-hermit, r=davidtwco

bors · bors · commit 48c0c2539542 · 2023-07-24T13:28:18.000Z
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
diff --git a/compiler/rustc_target/src/spec/aarch64_unknown_hermit.rs b/compiler/rustc_target/src/spec/aarch64_unknown_hermit.rs
@@ -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()
+        },
     }
 }
diff --git a/compiler/rustc_target/src/spec/hermit_base.rs b/compiler/rustc_target/src/spec/hermit_base.rs
@@ -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()
     }
 }
diff --git a/compiler/rustc_target/src/spec/mod.rs b/compiler/rustc_target/src/spec/mod.rs
@@ -1418,6 +1418,7 @@ supported_targets! {
     ("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),
diff --git a/compiler/rustc_target/src/spec/riscv64gc_unknown_hermit.rs b/compiler/rustc_target/src/spec/riscv64gc_unknown_hermit.rs
@@ -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()
+        },
+    }
+}
diff --git a/compiler/rustc_target/src/spec/x86_64_unknown_hermit.rs b/compiler/rustc_target/src/spec/x86_64_unknown_hermit.rs
@@ -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()
+        },
     }
 }
diff --git a/src/doc/rustc/src/SUMMARY.md b/src/doc/rustc/src/SUMMARY.md
@@ -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)
diff --git a/src/doc/rustc/src/platform-support.md b/src/doc/rustc/src/platform-support.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
diff --git a/src/doc/rustc/src/platform-support/hermit.md b/src/doc/rustc/src/platform-support/hermit.md
@@ -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.
diff --git a/src/tools/build-manifest/src/main.rs b/src/tools/build-manifest/src/main.rs
@@ -122,6 +122,7 @@ static TARGETS: &[&str] = &[
     "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",
