Stream: wamr

Topic: Rust + WIT to Core Wasm Module for running in WAMR

Robin Verbeelen (Apr 17 2025 at 03:41):

This post is something cross-channel going, but since my end goal is running in WAMR, I guess this is the best channel to ask about it...

I'm trying to find the "easiest" way of supporting WIT interfaces in an application that needs to run in the WAMR runtime. I don't necessarily want a best effort approach, but I really wanna know what tools are lacking atm or maybe there is a straightforward solution already. I know WAMR doesn't support this (yet), but I'm looking for a way of converting builds to a format that is supported
Lots of posts are a bit older and I'm trying to get a clear vision of what the state is in todays tooling options. Is there any clear winner in how to convert a wasm component to a core module? Essentially, I wanna be able to write some Rust code using a wasi WIT interface and compile it to a core WASM Module.

In the build flow of cargo-component I read that a core module actually gets wrapped to a component, so my guess is that it wouldn't be that difficult to just get a module instead? But I can't seem to figure out how to achieve this?
Using the --target wasm32-wasip1 didn't really work either.

If it helps, I'm trying to advance the I2C proposal and I'm trying to figure out how to build the right tooling to support the interface in WAMR

Christof Petig (Apr 17 2025 at 06:51):

I think I created some pieces which can help you, but I got distracted by my WASI 0.3 compiled to native projects.

At https://github.com/cpetig/wasmtime-adapter/tree/adapter/tests/preview2-adapter you can find a very simple example on how to create a core module (compatible with wamr) with wasip2 interfaces. This uses a static library to adapt from wasip1 to WASI 0.2 interfaces and thus can create a wasm 2.0+ core module.

Another example of using components in wamr is in https://github.com/cpetig/resource-demo/tree/main/host-wamr.

Ideally https://github.com/WebAssembly/component-model/pull/378 would get ready to enable a stable binary representation for core modules and someone would change wasi-libc to directly target wasip2+ instead of relying on the adapter, because the traditional adapter requires a component binary, which combines multiple core modules with a connecting fabric in a single non-wamr compatible binary format.

Christof Petig (Apr 17 2025 at 07:00):

Oh, and of course a WIT C host code generator would be needed for the implementations on wamr side, I started something similar years ago, today I would go for the less convenient "C header file without lifting/lowering" minimum viable product, as proposed in the SIG embedded.

Merlijn Sebrechts (Apr 22 2025 at 15:06):

So, to be clear, we don't necessarily want to support wasip2 interfaces in WAMR. Instead, we just want to support an interface defined in WIT. If there is a way to turn these into wasip1 interfaces than that would be enough.

So my (probably wrong) thought process would go like this:

1. Generate bindings from wit to the target language using wit-bindgen.
2. Compile to wasm32-wasip1 like so: https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/build_wasm_app.md (to get native wasip1 interfaces)
3. Manually write host code for the WIT interfaces we're using

Would this work? What am I missing here?

Merlijn Sebrechts (Apr 22 2025 at 15:43):

@Christof Petig About the "C header file without liting/lowering", I'm assuming you mean just hand-crafting a C header file for the interface that matches the ABI interpretation of the WIT? And then the applications use the ABI types directly instead of first converting them to a "language-native" format?

In that case, how would you go about crafting the C header file? Just use wit-bindgen to C and manually invert?

Christof Petig (Apr 22 2025 at 18:15):

I feel most of wit-bindgen would not be needed, also you probably want a special wamr host encoding (I created most of this but lost the need for it), probably a separate crate leveraging wit-bindgen-c would be ideal.

Christof Petig (Apr 22 2025 at 18:18):

On the other hand I feel that you will want to generate header declarations for the data types passed in pointers. You can find my c++ inspired code in my wit-bindgen fork, it already creates wamr registration code, but I didn't test it for two years.

Robin Verbeelen (May 01 2025 at 22:59):

I feel like I need more information on a deeper level and maybe my questions will be useful for other people in the future too, so:

Question 1

I feel most of wit-bindgen would not be needed

How come this wouldn't be needed? What does it do differently? Is the result too "heavy" for constrained devices? Is there another tool better suited for this use-case? Or does it simply not exist yet or will it ever exist?

Question 2

The dream would be to have something like:
| src/
--> main.rs
| wit/
--> i2c.wit
--> delay.wit

// main.rs
wit_bindgen::generate("../wit/")
 /* guest code */

and just compile using --target wasm32-wasip1 and have a wasm guest file that can be run by wamr, but I feel like we're just not there yet.
What are we exactly missing to make this work on wamr? How do we get just a core module that works with wasi p1, tho "using" the wit files to make sure the interface is correctly implemented?

Question 3

you probably want a special wamr host encoding (I created most of this but lost the need for it), probably a separate crate leveraging wit-bindgen-c would be ideal

What exactly would this be needed for? What's the goal this would want to achieve? What do you mean with special wamr host encoding?

-- @Christof Petig Thank you so much already for answering and taking your time to educate me a little on this

Last updated: Dec 06 2025 at 07:03 UTC