add missing description of the target aarch64-unknown-none-hermitkernel

This commit is contained in:
Stefan Lankes 2022-02-07 00:13:45 +01:00
parent 0b269f33f4
commit 10ae04a157
2 changed files with 81 additions and 3 deletions

View File

@ -204,7 +204,8 @@ target | std | host | notes
`aarch64-apple-tvos` | * | | ARM64 tvOS
[`aarch64-kmc-solid_asp3`](platform-support/kmc-solid.md) | ✓ | | ARM64 SOLID with TOPPERS/ASP3
`aarch64-unknown-freebsd` | ✓ | ✓ | ARM64 FreeBSD
`aarch64-unknown-hermit` | ? | |
`aarch64_unknown_hermit` | ✓ | |ARM64 HermitCore
[`aarch64_unknown_none_hermitkernel`](platform-support/aarch64-unknown-none-hermitkernel.md) | * | | ARM64 HermitCore kernel
`aarch64-unknown-uefi` | * | | ARM64 UEFI
`aarch64-unknown-linux-gnu_ilp32` | ✓ | ✓ | ARM64 Linux (ILP32 ABI)
`aarch64-unknown-netbsd` | ✓ | ✓ |
@ -286,10 +287,10 @@ 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` | ? | |
`x86_64-unknown-hermit` | ✓ | | HermitCore
`x86_64-unknown-l4re-uclibc` | ? | |
[`x86_64-unknown-none`](platform-support/x86_64-unknown-none.md) | * | | Freestanding/bare-metal x86_64, softfloat
`x86_64-unknown-none-hermitkernel` | ? | | HermitCore kernel
`x86_64-unknown-none-hermitkernel` | * | | HermitCore kernel
`x86_64-unknown-none-linuxkernel` | * | | Linux kernel modules
[`x86_64-unknown-openbsd`](platform-support/openbsd.md) | ✓ | ✓ | 64-bit OpenBSD
`x86_64-unknown-uefi` | * | | 64-bit UEFI

View File

@ -0,0 +1,77 @@
# `aarch64-unknown-none-hermitkernel`
**Tier: 3**
Required to build the kernel for [HermitCore](https://github.com/hermitcore/hermit-playground)
or [RustyHermit](https://github.com/hermitcore/rusty-hermit).
The result is a bare-metal aarch64 binary in ELF format.
## Target maintainers
- Stefan Lankes, https://github.com/stlankes
## Requirements
This target is cross-compiled. There is no support for `std`, but the
library operating system provides a simple allocator to use `alloc`.
By default, Rust code generated for this target does not use any vector or
floating-point registers. This allows the generated code to build the library
operaring system, which may need to avoid the use of such
registers or which may have special considerations about the use of such
registers (e.g. saving and restoring them to avoid breaking userspace code
using the same registers). In contrast to `aarch64-unknown-none-softfloat`,
the target is completly relocatable, which is a required feature of RustyHermit.
By default, code generated with this target should run on any `aarch64`
hardware; enabling additional target features may raise this baseline.
On `aarch64-unknown-none-hermitkernel`, `extern "C"` uses the [standard System V calling
convention](https://github.com/ARM-software/abi-aa/releases/download/2021Q3/sysvabi64.pdf),
without red zones.
This target generated binaries in the ELF format.
## Building the target
Typical you should not use the target directly. The target `aarch64-unknown-hermit`
builds the _user space_ of RustyHermit and supports red zones and floating-point
operations.
To build and link the kernel to the application, the crate
[hermit-sys](https://github.com/hermitcore/rusty-hermit/tree/master/hermit-sys)
should be used by adding the following lines to the `Cargo.toml` file of
your application.
```toml
[target.'cfg(target_os = "hermit")'.dependencies]
hermit-sys = "0.1.*"
```
The crate `hermit-sys` uses the target `aarch64-unknown-none-hermitkernel`
to build the kernel.
## Building Rust programs
Rust does not yet ship pre-compiled artifacts for this target. To compile for
this target, you need to build the crate `hermit-sys` (see
"Building the target" above).
## Testing
As `aarch64-unknown-none-hermitkernel` does not support `std`
and does not support running any Rust testsuite.
## Cross-compilation toolchains and C code
If you want to compile C code along with Rust you will need an
appropriate `aarch64` toolchain.
Rust *may* be able to use an `aarch64-linux-gnu-` toolchain with appropriate
standalone flags to build for this toolchain (depending on the assumptions of
that toolchain, see below), or you may wish to use a separate
`aarch64-unknown-none` (or `aarch64-elf-`) toolchain.
On some `aarch64` hosts that use ELF binaries, you *may* be able to use the host
C toolchain, if it does not introduce assumptions about the host environment
that don't match the expectations of a standalone environment. Otherwise, you
may need a separate toolchain for standalone/freestanding development, just as
when cross-compiling from a non-`aarch64` platform.