diff --git a/compiler/rustc_target/src/spec/mod.rs b/compiler/rustc_target/src/spec/mod.rs index ff5dfa3f74625..5bc6d1918dd7e 100644 --- a/compiler/rustc_target/src/spec/mod.rs +++ b/compiler/rustc_target/src/spec/mod.rs @@ -954,6 +954,8 @@ supported_targets! { ("armv6k-nintendo-3ds", armv6k_nintendo_3ds), ("armv7-unknown-linux-uclibceabihf", armv7_unknown_linux_uclibceabihf), + + ("x86_64-unknown-none", x86_64_unknown_none), } /// Warnings encountered when parsing the target `json`. diff --git a/compiler/rustc_target/src/spec/x86_64_unknown_none.rs b/compiler/rustc_target/src/spec/x86_64_unknown_none.rs new file mode 100644 index 0000000000000..722409dd168ce --- /dev/null +++ b/compiler/rustc_target/src/spec/x86_64_unknown_none.rs @@ -0,0 +1,41 @@ +// Generic x86-64 target for bare-metal code - Floating point disabled +// +// Can be used in conjunction with the `target-feature` and +// `target-cpu` compiler flags to opt-in more hardware-specific +// features. + +use super::{ + CodeModel, LinkerFlavor, LldFlavor, PanicStrategy, RelocModel, RelroLevel, StackProbeType, + Target, TargetOptions, +}; + +pub fn target() -> Target { + let opts = TargetOptions { + cpu: "x86-64".to_string(), + max_atomic_width: Some(64), + // don't use probe-stack=inline-asm until rust#83139 and rust#84667 are resolved + stack_probes: StackProbeType::Call, + position_independent_executables: true, + static_position_independent_executables: true, + relro_level: RelroLevel::Full, + relocation_model: RelocModel::Pic, + linker_flavor: LinkerFlavor::Lld(LldFlavor::Ld), + linker: Some("rust-lld".to_owned()), + features: + "-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2,+soft-float" + .to_string(), + executables: true, + disable_redzone: true, + panic_strategy: PanicStrategy::Abort, + code_model: Some(CodeModel::Kernel), + ..Default::default() + }; + Target { + llvm_target: "x86_64-unknown-none-elf".to_string(), + pointer_width: 64, + data_layout: "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" + .to_string(), + arch: "x86_64".to_string(), + options: opts, + } +} diff --git a/src/doc/rustc/src/SUMMARY.md b/src/doc/rustc/src/SUMMARY.md index 8c41835183797..c251425d1b7ad 100644 --- a/src/doc/rustc/src/SUMMARY.md +++ b/src/doc/rustc/src/SUMMARY.md @@ -15,6 +15,7 @@ - [Platform Support](platform-support.md) - [aarch64-apple-ios-sim](platform-support/aarch64-apple-ios-sim.md) - [\*-kmc-solid_\*](platform-support/kmc-solid.md) + - [x86_64-unknown-none](platform-support/x86_64-unknown-none.md) - [Target Tier Policy](target-tier-policy.md) - [Targets](targets/index.md) - [Built-in Targets](targets/built-in.md) diff --git a/src/doc/rustc/src/platform-support.md b/src/doc/rustc/src/platform-support.md index bbeab598f2292..6b0c336b3c799 100644 --- a/src/doc/rustc/src/platform-support.md +++ b/src/doc/rustc/src/platform-support.md @@ -285,6 +285,7 @@ target | std | host | notes `x86_64-unknown-haiku` | ✓ | ✓ | 64-bit Haiku `x86_64-unknown-hermit` | ? | | `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-linuxkernel` | * | | Linux kernel modules `x86_64-unknown-openbsd` | ✓ | ✓ | 64-bit OpenBSD diff --git a/src/doc/rustc/src/platform-support/x86_64-unknown-none.md b/src/doc/rustc/src/platform-support/x86_64-unknown-none.md new file mode 100644 index 0000000000000..afcc48003b936 --- /dev/null +++ b/src/doc/rustc/src/platform-support/x86_64-unknown-none.md @@ -0,0 +1,76 @@ +# `x86_64-unknown-none` + +**Tier: 3** + +Freestanding/bare-metal x86-64 binaries in ELF format: firmware, kernels, etc. + +## Target maintainers + +- Harald Hoyer `harald@profian.com`, https://github.com/haraldh +- Mike Leany, https://github.com/mikeleany + +## Requirements + +This target is cross-compiled. There is no support for `std`. There is no +default allocator, but it's possible to use `alloc` by supplying an allocator. + +By default, Rust code generated for this target does not use any vector or +floating-point registers (e.g. SSE, AVX). This allows the generated code to run +in environments, such as kernels, 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). You can change code generation to use additional CPU +features via the `-C target-feature=` codegen options to rustc, or via the +`#[target_feature]` mechanism within Rust code. + +By default, code generated with this target should run on any `x86_64` +hardware; enabling additional target features may raise this baseline. + +Code generated with this target will use the `kernel` code model by default. +You can change this using the `-C code-model=` option to rustc. + +On `x86_64-unknown-none`, `extern "C"` uses the [standard System V calling +convention](https://gitlab.com/x86-psABIs/x86-64-ABI), without red zones. + +This target generated binaries in the ELF format. Any alternate formats or +special considerations for binary layout will require linker options or linker +scripts. + +## Building the target + +You can build Rust with support for the target by adding it to the `target` +list in `config.toml`: + +```toml +[build] +build-stage = 1 +target = ["x86_64-unknown-none"] +``` + +## Building Rust programs + +Rust does not yet ship pre-compiled artifacts for this target. To compile for +this target, you will either need to build Rust with the target enabled (see +"Building the target" above), or build your own copy of `core` by using +`build-std` or similar. + +## Testing + +As `x86_64-unknown-none` supports a variety of different environments and does +not support `std`, this target does not support running the Rust testsuite. + +## Cross-compilation toolchains and C code + +If you want to compile C code along with Rust (such as for Rust crates with C +dependencies), you will need an appropriate `x86_64` toolchain. + +Rust *may* be able to use an `x86_64-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 +`x86_64-unknown-none` (or `x86_64-elf-`) toolchain. + +On some `x86_64` 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-`x86_64` platform.