This RFC is tied to PR #156087, discussing the addition of a target wasm32-wali-linux-musl for a Linux Interface for Wasm.
WALI provides a description of the Linux system call interface for Wasm. This target capability is already supported as a Tier-3 target in rustc, but requires an out-of-fork llvm build. Importantly, this is only a very minor ABI variation from the already existing WASI/emscripten targets, requiring minimal changes to the codebase (a TripleParser for this configuration, and Driver support).
Rust offers a large user base for the tooling of this platform and its adoption
Same as 1
Not applicable
Not applicable
I am willing to maintain the target and all supports around WALI
As stated earlier, only a very minor ABI change is needed for this specific target and no other existing targets are affected as a result
Tests have been added in the PR
Besides existing changes in working around the toolchain of libunwind to compile against this target, no additional features have been added to any of the supporting projects.
The main area of discussion around this was where to describe the wali description if at all. Linking it Zulip discussion from our Rust integration, the ‘vendor’ field was used primarily to allow compatibility with current feature gating around wasm32, linux, and musl. The target would ideally not need a vendor field, just specified as wasm32-linux-musl, but this can be discussed.
Since there is a different ABI with the size of long compared to other wasm targets, it would be good to have that distinguishable in the triple. I’m not sure if there’s precedent for using the vendor field for that. I would be curious if others have opinions on that specifically.
As someone who is working on a different wasm32-linux ABI, I’m personally appreciative of the vendor field here. I’d wait for community consensus or an upstream kernel definition before supporting an unqualified name.
I’m a bit wary of using the vendor field for this; we usually don’t distinguish ABIs by the vendor field. By usual standards, this should be either just wasm32-linux-muslwali or wasm32-linux-wali. We currently have a bunch of variants along these lines. But there’s generally a lot of weirdness in triples, so maybe it’s not a big deal.
Is the primary argument for not adding a new environment just the Rust #cfg usage?
The rust cfg settings are fully independent of LLVM. We could make this target MuslWali for LLVM without changing anything on the rust end. Basically we can decouple the rust target spec when making a decision on the LLVM triple name.