rust/compiler/rustc_target/src/spec/x86_64_unknown_uefi.rs

47 lines
2.4 KiB
Rust
Raw Normal View History

Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore, it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...). UEFI systems provide a very basic operating-system environment, meant to unify how systems are booted. It is tailored for simplicity and fast setup, as it is only meant to bootstrap other systems. For instance, it copies most of the ABI from Microsoft Windows, rather than inventing anything on its own. Furthermore, any complex CPU features are disabled. Only one CPU is allowed to be up, no interrupts other than the timer-interrupt are allowed, no process-separation is performed, page-tables are identity-mapped, ... Nevertheless, UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However, many other UEFI applications have emerged in the past, including network-boot, debug-consoles, and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added, but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore, liballoc works as well, if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike, none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore, several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.
2018-12-13 10:08:20 +01:00
// This defines the amd64 target for UEFI systems as described in the UEFI specification. See the
// uefi-base module for generic UEFI options. On x86_64 systems (mostly called "x64" in the spec)
// UEFI systems always run in long-mode, have the interrupt-controller pre-configured and force a
// single-CPU execution.
// The win64 ABI is used. It differs from the sysv64 ABI, so we must use a windows target with
// LLVM. "x86_64-unknown-windows" is used to get the minimal subset of windows-specific features.
use crate::spec::{CodeModel, LinkerFlavor, LldFlavor, Target};
Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore, it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...). UEFI systems provide a very basic operating-system environment, meant to unify how systems are booted. It is tailored for simplicity and fast setup, as it is only meant to bootstrap other systems. For instance, it copies most of the ABI from Microsoft Windows, rather than inventing anything on its own. Furthermore, any complex CPU features are disabled. Only one CPU is allowed to be up, no interrupts other than the timer-interrupt are allowed, no process-separation is performed, page-tables are identity-mapped, ... Nevertheless, UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However, many other UEFI applications have emerged in the past, including network-boot, debug-consoles, and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added, but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore, liballoc works as well, if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike, none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore, several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.
2018-12-13 10:08:20 +01:00
pub fn target() -> Target {
let mut base = super::uefi_msvc_base::opts();
Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore, it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...). UEFI systems provide a very basic operating-system environment, meant to unify how systems are booted. It is tailored for simplicity and fast setup, as it is only meant to bootstrap other systems. For instance, it copies most of the ABI from Microsoft Windows, rather than inventing anything on its own. Furthermore, any complex CPU features are disabled. Only one CPU is allowed to be up, no interrupts other than the timer-interrupt are allowed, no process-separation is performed, page-tables are identity-mapped, ... Nevertheless, UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However, many other UEFI applications have emerged in the past, including network-boot, debug-consoles, and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added, but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore, liballoc works as well, if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike, none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore, several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.
2018-12-13 10:08:20 +01:00
base.cpu = "x86-64".to_string();
base.max_atomic_width = Some(64);
// We disable MMX and SSE for now, even though UEFI allows using them. Problem is, you have to
// enable these CPU features explicitly before their first use, otherwise their instructions
// will trigger an exception. Rust does not inject any code that enables AVX/MMX/SSE
// instruction sets, so this must be done by the firmware. However, existing firmware is known
// to leave these uninitialized, thus triggering exceptions if we make use of them. Which is
// why we avoid them and instead use soft-floats. This is also what GRUB and friends did so
// far.
// If you initialize FP units yourself, you can override these flags with custom linker
// arguments, thus giving you access to full MMX/SSE acceleration.
Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore, it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...). UEFI systems provide a very basic operating-system environment, meant to unify how systems are booted. It is tailored for simplicity and fast setup, as it is only meant to bootstrap other systems. For instance, it copies most of the ABI from Microsoft Windows, rather than inventing anything on its own. Furthermore, any complex CPU features are disabled. Only one CPU is allowed to be up, no interrupts other than the timer-interrupt are allowed, no process-separation is performed, page-tables are identity-mapped, ... Nevertheless, UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However, many other UEFI applications have emerged in the past, including network-boot, debug-consoles, and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added, but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore, liballoc works as well, if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike, none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore, several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.
2018-12-13 10:08:20 +01:00
base.features = "-mmx,-sse,+soft-float".to_string();
// UEFI systems run without a host OS, hence we cannot assume any code locality. We must tell
// LLVM to expect code to reference any address in the address-space. The "large" code-model
// places no locality-restrictions, so it fits well here.
base.code_model = Some(CodeModel::Large);
Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore, it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...). UEFI systems provide a very basic operating-system environment, meant to unify how systems are booted. It is tailored for simplicity and fast setup, as it is only meant to bootstrap other systems. For instance, it copies most of the ABI from Microsoft Windows, rather than inventing anything on its own. Furthermore, any complex CPU features are disabled. Only one CPU is allowed to be up, no interrupts other than the timer-interrupt are allowed, no process-separation is performed, page-tables are identity-mapped, ... Nevertheless, UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However, many other UEFI applications have emerged in the past, including network-boot, debug-consoles, and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added, but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore, liballoc works as well, if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike, none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore, several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.
2018-12-13 10:08:20 +01:00
Target {
Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore, it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...). UEFI systems provide a very basic operating-system environment, meant to unify how systems are booted. It is tailored for simplicity and fast setup, as it is only meant to bootstrap other systems. For instance, it copies most of the ABI from Microsoft Windows, rather than inventing anything on its own. Furthermore, any complex CPU features are disabled. Only one CPU is allowed to be up, no interrupts other than the timer-interrupt are allowed, no process-separation is performed, page-tables are identity-mapped, ... Nevertheless, UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However, many other UEFI applications have emerged in the past, including network-boot, debug-consoles, and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added, but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore, liballoc works as well, if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike, none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore, several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.
2018-12-13 10:08:20 +01:00
llvm_target: "x86_64-unknown-windows".to_string(),
target_endian: "little".to_string(),
target_pointer_width: "64".to_string(),
target_c_int_width: "32".to_string(),
data_layout: "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
.to_string(),
Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore, it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...). UEFI systems provide a very basic operating-system environment, meant to unify how systems are booted. It is tailored for simplicity and fast setup, as it is only meant to bootstrap other systems. For instance, it copies most of the ABI from Microsoft Windows, rather than inventing anything on its own. Furthermore, any complex CPU features are disabled. Only one CPU is allowed to be up, no interrupts other than the timer-interrupt are allowed, no process-separation is performed, page-tables are identity-mapped, ... Nevertheless, UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However, many other UEFI applications have emerged in the past, including network-boot, debug-consoles, and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added, but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore, liballoc works as well, if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike, none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore, several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.
2018-12-13 10:08:20 +01:00
target_os: "uefi".to_string(),
target_env: "".to_string(),
target_vendor: "unknown".to_string(),
arch: "x86_64".to_string(),
linker_flavor: LinkerFlavor::Lld(LldFlavor::Link),
options: base,
}
Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore, it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...). UEFI systems provide a very basic operating-system environment, meant to unify how systems are booted. It is tailored for simplicity and fast setup, as it is only meant to bootstrap other systems. For instance, it copies most of the ABI from Microsoft Windows, rather than inventing anything on its own. Furthermore, any complex CPU features are disabled. Only one CPU is allowed to be up, no interrupts other than the timer-interrupt are allowed, no process-separation is performed, page-tables are identity-mapped, ... Nevertheless, UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However, many other UEFI applications have emerged in the past, including network-boot, debug-consoles, and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added, but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore, liballoc works as well, if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike, none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore, several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.
2018-12-13 10:08:20 +01:00
}