-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add a new
wasm32-wasip1 target to rustc
This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
- Loading branch information
1 parent
5257aee
commit cb39d6c
Showing
15 changed files
with
213 additions
and
125 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,119 +1,11 @@ | ||
| //! The `wasm32-wasi` target is a new and still (as of April 2019) an | ||
| //! experimental target. The definition in this file is likely to be tweaked | ||
| //! over time and shouldn't be relied on too much. | ||
| //! NB: This target is in the process of being renamed to | ||
| //! `wasm32-wasip1`. For more information see: | ||
| //! | ||
| //! The `wasi` target is a proposal to define a standardized set of syscalls | ||
| //! that WebAssembly files can interoperate with. This set of syscalls is | ||
| //! intended to empower WebAssembly binaries with native capabilities such as | ||
| //! filesystem access, network access, etc. | ||
| //! | ||
| //! You can see more about the proposal at <https://wasi.dev>. | ||
| //! | ||
| //! The Rust target definition here is interesting in a few ways. We want to | ||
| //! serve two use cases here with this target: | ||
| //! | ||
| //! * First, we want Rust usage of the target to be as hassle-free as possible, | ||
| //! ideally avoiding the need to configure and install a local wasm32-wasi | ||
| //! toolchain. | ||
| //! | ||
| //! * Second, one of the primary use cases of LLVM's new wasm backend and the | ||
| //! wasm support in LLD is that any compiled language can interoperate with | ||
| //! any other. To that the `wasm32-wasi` target is the first with a viable C | ||
| //! standard library and sysroot common definition, so we want Rust and C/C++ | ||
| //! code to interoperate when compiled to `wasm32-unknown-unknown`. | ||
| //! | ||
| //! You'll note, however, that the two goals above are somewhat at odds with one | ||
| //! another. To attempt to solve both use cases in one go we define a target | ||
| //! that (ab)uses the `crt-static` target feature to indicate which one you're | ||
| //! in. | ||
| //! | ||
| //! ## No interop with C required | ||
| //! | ||
| //! By default the `crt-static` target feature is enabled, and when enabled | ||
| //! this means that the bundled version of `libc.a` found in `liblibc.rlib` | ||
| //! is used. This isn't intended really for interoperation with a C because it | ||
| //! may be the case that Rust's bundled C library is incompatible with a | ||
| //! foreign-compiled C library. In this use case, though, we use `rust-lld` and | ||
| //! some copied crt startup object files to ensure that you can download the | ||
| //! wasi target for Rust and you're off to the races, no further configuration | ||
| //! necessary. | ||
| //! | ||
| //! All in all, by default, no external dependencies are required. You can | ||
| //! compile `wasm32-wasi` binaries straight out of the box. You can't, however, | ||
| //! reliably interoperate with C code in this mode (yet). | ||
| //! | ||
| //! ## Interop with C required | ||
| //! | ||
| //! For the second goal we repurpose the `target-feature` flag, meaning that | ||
| //! you'll need to do a few things to have C/Rust code interoperate. | ||
| //! | ||
| //! 1. All Rust code needs to be compiled with `-C target-feature=-crt-static`, | ||
| //! indicating that the bundled C standard library in the Rust sysroot will | ||
| //! not be used. | ||
| //! | ||
| //! 2. If you're using rustc to build a linked artifact then you'll need to | ||
| //! specify `-C linker` to a `clang` binary that supports | ||
| //! `wasm32-wasi` and is configured with the `wasm32-wasi` sysroot. This | ||
| //! will cause Rust code to be linked against the libc.a that the specified | ||
| //! `clang` provides. | ||
| //! | ||
| //! 3. If you're building a staticlib and integrating Rust code elsewhere, then | ||
| //! compiling with `-C target-feature=-crt-static` is all you need to do. | ||
| //! | ||
| //! You can configure the linker via Cargo using the | ||
| //! `CARGO_TARGET_WASM32_WASI_LINKER` env var. Be sure to also set | ||
| //! `CC_wasm32-wasi` if any crates in the dependency graph are using the `cc` | ||
| //! crate. | ||
| //! | ||
| //! ## Remember, this is all in flux | ||
| //! | ||
| //! The wasi target is **very** new in its specification. It's likely going to | ||
| //! be a long effort to get it standardized and stable. We'll be following it as | ||
| //! best we can with this target. Don't start relying on too much here unless | ||
| //! you know what you're getting in to! | ||
| //! * <https://github.com/rust-lang/compiler-team/issues/607> | ||
| //! * <https://github.com/rust-lang/compiler-team/issues/695> | ||
|
|
||
| use crate::spec::crt_objects; | ||
| use crate::spec::LinkSelfContainedDefault; | ||
| use crate::spec::{base, Cc, LinkerFlavor, Target}; | ||
| use crate::spec::Target; | ||
|
|
||
| pub fn target() -> Target { | ||
| let mut options = base::wasm::options(); | ||
|
|
||
| options.os = "wasi".into(); | ||
| options.add_pre_link_args(LinkerFlavor::WasmLld(Cc::Yes), &["--target=wasm32-wasi"]); | ||
|
|
||
| options.pre_link_objects_self_contained = crt_objects::pre_wasi_self_contained(); | ||
| options.post_link_objects_self_contained = crt_objects::post_wasi_self_contained(); | ||
|
|
||
| // FIXME: Figure out cases in which WASM needs to link with a native toolchain. | ||
| options.link_self_contained = LinkSelfContainedDefault::True; | ||
|
|
||
| // Right now this is a bit of a workaround but we're currently saying that | ||
| // the target by default has a static crt which we're taking as a signal | ||
| // for "use the bundled crt". If that's turned off then the system's crt | ||
| // will be used, but this means that default usage of this target doesn't | ||
| // need an external compiler but it's still interoperable with an external | ||
| // compiler if configured correctly. | ||
| options.crt_static_default = true; | ||
| options.crt_static_respected = true; | ||
|
|
||
| // Allow `+crt-static` to create a "cdylib" output which is just a wasm file | ||
| // without a main function. | ||
| options.crt_static_allows_dylibs = true; | ||
|
|
||
| // WASI's `sys::args::init` function ignores its arguments; instead, | ||
| // `args::args()` makes the WASI API calls itself. | ||
| options.main_needs_argc_argv = false; | ||
|
|
||
| // And, WASI mangles the name of "main" to distinguish between different | ||
| // signatures. | ||
| options.entry_name = "__main_void".into(); | ||
|
|
||
| Target { | ||
| llvm_target: "wasm32-wasi".into(), | ||
| pointer_width: 32, | ||
| data_layout: "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20".into(), | ||
| arch: "wasm32".into(), | ||
| options, | ||
| } | ||
| super::wasm32_wasip1::target() | ||
| } |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,57 @@ | ||
| //! The `wasm32-wasip1` enables compiling to WebAssembly using the first | ||
| //! version of the WASI standard, called "preview1". This version of the | ||
| //! standard was never formally specified and WASI has since evolved to a | ||
| //! "preview2". This target in rustc uses the previous version of the proposal. | ||
| //! | ||
| //! This target uses the syscalls defined at | ||
| //! <https://github.com/WebAssembly/WASI/tree/main/legacy/preview1>. | ||
| //! | ||
| //! Note that this target was historically called `wasm32-wasi` originally and | ||
| //! was since renamed to `wasm32-wasip1` after the preview2 target was | ||
| //! introduced. | ||
|
|
||
| use crate::spec::crt_objects; | ||
| use crate::spec::LinkSelfContainedDefault; | ||
| use crate::spec::{base, Cc, LinkerFlavor, Target}; | ||
|
|
||
| pub fn target() -> Target { | ||
| let mut options = base::wasm::options(); | ||
|
|
||
| options.os = "wasi".into(); | ||
| options.add_pre_link_args(LinkerFlavor::WasmLld(Cc::Yes), &["--target=wasm32-wasi"]); | ||
|
|
||
| options.pre_link_objects_self_contained = crt_objects::pre_wasi_self_contained(); | ||
| options.post_link_objects_self_contained = crt_objects::post_wasi_self_contained(); | ||
|
|
||
| // FIXME: Figure out cases in which WASM needs to link with a native toolchain. | ||
| options.link_self_contained = LinkSelfContainedDefault::True; | ||
|
|
||
| // Right now this is a bit of a workaround but we're currently saying that | ||
| // the target by default has a static crt which we're taking as a signal | ||
| // for "use the bundled crt". If that's turned off then the system's crt | ||
| // will be used, but this means that default usage of this target doesn't | ||
| // need an external compiler but it's still interoperable with an external | ||
| // compiler if configured correctly. | ||
| options.crt_static_default = true; | ||
| options.crt_static_respected = true; | ||
|
|
||
| // Allow `+crt-static` to create a "cdylib" output which is just a wasm file | ||
| // without a main function. | ||
| options.crt_static_allows_dylibs = true; | ||
|
|
||
| // WASI's `sys::args::init` function ignores its arguments; instead, | ||
| // `args::args()` makes the WASI API calls itself. | ||
| options.main_needs_argc_argv = false; | ||
|
|
||
| // And, WASI mangles the name of "main" to distinguish between different | ||
| // signatures. | ||
| options.entry_name = "__main_void".into(); | ||
|
|
||
| Target { | ||
| llvm_target: "wasm32-wasi".into(), | ||
| pointer_width: 32, | ||
| data_layout: "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20".into(), | ||
| arch: "wasm32".into(), | ||
| options, | ||
| } | ||
| } |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,119 @@ | ||
| # `wasm32-wasip1` | ||
|
|
||
| **Tier: 2** | ||
|
|
||
| The `wasm32-wasip1` target is a WebAssembly compilation target which | ||
| assumes that the [WASIp1] (aka "WASI preview1") set of "syscalls" are available | ||
| for use in the standard library. Historically this target in the Rust compiler | ||
| was one of the first for WebAssembly where Rust and C code are explicitly | ||
| intended to interoperate as well. | ||
|
|
||
| There's a bit of history to the target and current development which is also | ||
| worth explaining before going much further. Historically this target was | ||
| originally called `wasm32-wasi` in both rustc and Clang. This was first added | ||
| to Rust in 2019. In the intervening years leading up to 2024 the WASI standard | ||
| continued to be developed and was eventually "rebased" on top of the [Component | ||
| Model]. This was a large change to the WASI specification and was released as | ||
| 0.2.0 ("WASIp2" colloquially) in January 2024. The previous target's name in | ||
| rustc, `wasm32-wasi`, was then renamed to `wasm32-wasip1`, to avoid | ||
| confusion with this new target to be added to rustc as `wasm32-wasip2`. | ||
| Some more context can be found in these MCPs: | ||
|
|
||
| * [Rename wasm32-wasi target to wasm32-wasip1](https://github.com/rust-lang/compiler-team/issues/607) | ||
| * [Smooth the renaming transition of wasm32-wasi](https://github.com/rust-lang/compiler-team/issues/695) | ||
|
|
||
| At this point the `wasm32-wasip1` target is intended for historical | ||
| compatibility with the first version of the WASI standard. As of now (January | ||
| 2024) the 0.2.0 target of WASI ("WASIp2") is relatively new. The state of | ||
| WASI will likely change in few years after which point this documentation will | ||
| probably receive another update. | ||
|
|
||
| [WASI Preview1]: https://github.com/WebAssembly/WASI/tree/main/legacy/preview1 | ||
| [Component Model]: https://github.com/webassembly/component-model | ||
|
|
||
| Today the `wasm32-wasip1` target will generate core WebAssembly modules | ||
| which will import functions from the `wasi_snapshot_preview1` module for | ||
| OS-related functionality (e.g. printing). | ||
|
|
||
| ## Target maintainers | ||
|
|
||
| When this target was added to the compiler platform-specific documentation here | ||
| was not maintained at that time. This means that the list below is not | ||
| exhaustive and there are more interested parties in this target. That being | ||
| said since when this document was last updated those interested in maintaining | ||
| this target are: | ||
|
|
||
| - Alex Crichton, https://github.com/alexcrichton | ||
|
|
||
| ## Requirements | ||
|
|
||
| This target is cross-compiled. The target includes support for `std` itself, | ||
| but not all of the standard library works. For example spawning a thread will | ||
| always return an error (see the `wasm32-wasi-preview1-threads` target for | ||
| example). Another example is that spawning a process will always return an | ||
| error. Operations such as opening a file, however, will be implemented by | ||
| calling WASI-defined APIs. | ||
|
|
||
| The WASI targets for Rust are explicitly intended to interoperate with other | ||
| languages compiled to WebAssembly, for example C/C++. Any ABI differences or | ||
| mismatches are considered bugs that need to be fixed. | ||
|
|
||
| By default the WASI targets in Rust ship in rustup with a precompiled copy of | ||
| [`wasi-libc`] meaning that a WebAssembly-targetting-Clang is not required to | ||
| use the WASI targets from Rust. If there is no actual interoperation with C | ||
| then `rustup target add wasm32-wasip1` is all that's needed to get | ||
| started with WASI. | ||
|
|
||
| Note that this behavior can be controlled with `-Clinker` and | ||
| `-Clink-self-contained`, however. By specifying `clang` as a linker and | ||
| disabling the `link-self-contained` option an external version of `libc.a` can | ||
| be used instead. | ||
|
|
||
| [`wasi-libc`]: https://github.com/WebAssembly/wasi-libc | ||
|
|
||
| ## Building the target | ||
|
|
||
| To build this target a compiled version of [`wasi-libc`] is required to be | ||
| present at build time. This can be installed through | ||
| [`wasi-sdk`](https://github.com/WebAssembly/wasi-sdk) as well. This is the | ||
| configured with: | ||
|
|
||
| ```toml | ||
| [target.wasm32-wasip1] | ||
| wasi-root = ".../wasi-libc/sysroot" | ||
| ``` | ||
|
|
||
| Additionally users will need to enable LLD when building Rust from source as | ||
| LLVM's `wasm-ld` driver for LLD is required when linking WebAssembly code | ||
| together. | ||
|
|
||
| ## Building Rust programs | ||
|
|
||
| The `wasm32-wasip1` target is shipped with rustup so users can install | ||
| the target with: | ||
|
|
||
| ```text | ||
| rustup target add wasm32-wasip1 | ||
| ``` | ||
|
|
||
| > **Note**: the `wasm32-wasip1` target is new and may only be available | ||
| > on nightly by the time you're reading this. If `wasm32-wasip1` isn't | ||
| > available on stable Rust then `wasm32-wasi` should be available instead. | ||
| Rust programs can be built for that target: | ||
|
|
||
| ```text | ||
| rustc --target wasm32-wasip1 your-code.rs | ||
| ``` | ||
|
|
||
| ## Cross-compilation | ||
|
|
||
| This target can be cross-compiled from any hosts. | ||
|
|
||
| ## Testing | ||
|
|
||
| Currently the WASI target is not tested in rust-lang/rust CI. This means that | ||
| tests in the repository are not guaranteed to pass. This is theoretically | ||
| possibly by installing a standalone WebAssembly runtime and using it as a | ||
| "runner" for all tests, but there are various failures that will need to be | ||
| waded through to adjust tests to work on the WASI target. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.