Following a really cool blog post “A beginner’s guide to adding a new WASI syscall in Wasmtime”
by @RaduM on adding a new WASI syscall to the WASI spec and then stubbing it
out in Wasmtime, I thought I’ll contribute to his
effort in making Wasm and WASI simpler for the beginners, and delve a bit deeper into stubbing out WASI imports
manually when compiling from Rust using the bare target wasm32-unknown-unknown
. I guess I’m
hopeful this would hint everyone on how wasm-bindgen is doing
it, or what is actually happening under-the-hood when compiling directly to WASI in Rust (i.e., using the
target wasm32-wasi
).
Excellent question! So here’s the problem we’re trying to solve here. Given a simple, bare Rust lib looking as follows:
how can we configure and stub it out so that when compiled to wasm32-unknown-unknown
it’s actually run as
a standard executable WASI module? Incidentally, the solution to this problem is pretty straightforward once
you know what the WASI spec requires, and how to link to the runtime-provided syscall module. But, one thing at a time.
You’ll need:
wasm32-unknown-unknown
target installed:
After you’ve gathered all three, go ahead and create a Rust library template with:
What we actually want here is for the library to compile into a dynamic system library, or cdylib
.
To do that, we need to tweak Cargo.toml
to have the following [lib]
section added:
cdylib
will allow us to build a dynamically linked Wasm module. With the right entrypoint specified, this will
allows to use it as a standard executable Wasm module that you would get by compiling a binary Rust crate
to wasm32-wasi
target directly. You can find more on this here.
At the time of writing, for a Wasm module to classify as a WASI module, it needs to export an entrypoint
called _start
. Cool, this is easy, let’s add that in to our lib.rs
source:
Note the #[no_mangle]
attribute which will basically stop Rust compiler from mangling the function’s name,
and extern "C"
since we need to generate ABI that our Wasm runtime (in this case, Wasmtime
) can link to.
OK, so this is one is the trickiest step so far. Since we’re stubbing out the WASI imports/exports ourselves,
println!
macro won’t work as it has no idea where to redirect the output to. If we compiled to wasm32-wasi
that would have been taken care of for us, but in this case, we’ll have to do this manually ourselves.
We’ll need to import two WASI syscalls provided by the runtime when executing our module. These are:
fd_write
– allows writing to a WASI file descriptor (in our case, we’ll redirect to stdout)
proc_exit
– terminates the process with the specified exit code
They’re both provided as part of the wasi_snapshot_preview1
module which we’ll link to in our module.
Oh, and btw, you can explore the WASI spec, and in particular, wasi_snapshot_preview1
module in more
detail here.
We’ll need the following set of imports declared and types/structs defined:
A word of explanation what the heck is going on here. In order to link with the syscalls provided by
the runtime, we need to match the function name and its signature. For the latter to work out, we need
to be careful to properly specify the sizes (in bytes) of the input types, and so, under-the-hood,
the runtime is expecting a function fd_write
to have the signature
i32
here means that every type is 4 bytes aligned.
say_hello
OK, with this out of the way, we can finally stub out say_hello
function with a working replacement
of println!
:
And our entrypoint:
And that’s it! We can compile our module and run using Wasmtime
.
wasm32-unknown-unknown
If there were no errors, you should find your Wasm module in target/wasm32-unknown-unknown/debug/hello_wasi.wasm
.
Wasmtime
To check that we’re actually calling the syscalls from our module, we can enable the syscall trace like so:
I hope this has been useful for you. If I have made a mistake anywhere (which I most likely have), please feel free to reach out to me via any means available :-)