diff options
| author | Pietro Albini <pietro@pietroalbini.org> | 2018-12-15 10:17:39 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-12-15 10:17:39 +0100 |
| commit | 1116546e170dcc2951a541ebe38855ae746d8847 (patch) | |
| tree | 6b6400c6f8cf9011c3d5d417fe95343e70079cb5 /src/libstd/sys/wasm/stack_overflow.rs | |
| parent | e433da7ea077208f09f004675da8927f5ddbb405 (diff) | |
| parent | 88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3 (diff) | |
| download | rust-1116546e170dcc2951a541ebe38855ae746d8847.tar.gz rust-1116546e170dcc2951a541ebe38855ae746d8847.zip | |
Rollup merge of #56769 - dvdhrm:uefi-target, r=alexcrichton
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.
Diffstat (limited to 'src/libstd/sys/wasm/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
