Using linked module from the Wasmtime generated code results in missing `canonical_abi_free` export

[radu-matei]

The use case is the following: I am using the generated export Wasmtime bindings to execute a specific function through Wasmtime. This works fine for modules that have not been linked, but fails for modules that import any interfaces and need to be linked.

(First, the module must export a _start function. Adding a dummy _start bypasses this)

The error I'm seeing: "failed to find function export canonical_abi_free".

The Wasmtime bindings explicitly try to use the free function (when using strings in the function signatures), and apparently the linked module does not re-export it.

A couple of questions:

• is there a reason to explicitly require the _start function before linking a module?
• is there a way to re-export the canonical_abi_free function (and I assume the same is valid for the realloc function)?

Thanks!

cc @peterhuene

[peterhuene]

Hi Radu.

There's no reason to require _start as an export from the "main" module; we should simply be re-exporting all exported functions, _start and canonical_abi_* included.

I'll get this fixed tomorrow.

[saona-raimundo]

Hi there!

First of all, thank you for the great work!! I was poking around and it looks fantastic!

About this issue, is there any reason why the canonical_abi_* (realloc and free) is not part of the current generated bindings? Say, to the result of a Rust-export.

If these functions are not supposed to be in any particular generated bindings (I assume because they would be part of some sort of "linker", to not have code repetition), where is this linker supposed to be?

Comments

I know about the wasmlink crate, but it seems that it would constrain the host to compile to wasm. Please correct me if I am wrong.

Use case

I want an app written in Rust that uses wasmtime-the-crate to run wasm modules. These wasm modules implement the functions in some .wit file. The .wit file is like the "public plugin API": if you want my app to run your plugin, implement the functions in this .wit file.

When I tried to put this setup together, compiling some .wasm "plugin" was easy, thanks to wit-bindgen :).
When I tried to run the wasm through wasmtime-the-crate in my app, I needed wasi (okay, added to the linker) and also the canonical_abi_free function.

This was nowhere to be found, except as part of the rust-wasm crate.

Easy-fix

Adding canonical_abi_free function to the generated bindings of Rust-export solved the issue. Now the wasm module that I will call has its own canonical_abi_free function, so it is available when I asked wasmtime-the-crate to run the functions defined in my .wit.

On code repetition

If canonical_abi_* are added to every binding generated, there would lot of code repetition, right? All you need is this function once. But looking at the Wasmtime-import binding generated, it feels like these functions are meant to be exactly there: in the Rust-export code.
What is the correct way to add these functions in my use case?
Should I add them to the Wastime::Linker somehow?
Should the crate rust-wasm have a function add_to_linker, similar to wasmtime_wasi::sync::add_to_linker?

[alexcrichton]

Currently the various intrinsics are provided in Rust via the runtime crate itself. It's not intended that the wit-bindgen CLI tool is used literally per se for Rust, but rather the wit-bindgen-{rust,wasmtime} crates would be used with their procedural macros to get all the runtime support to line up. Does that work for you?

[saona-raimundo]

I am really sorry, I thought I had understood what was going on, but it seems I did not.

Using the macros in the wit-bindgen-{rust,wasmtime} crates works like a charm. I simply started again from the demo in wasmlink and it worked.

So... just for curiosity, in which step are the canonical_abi_* functions included?

In case it is needed, this is my setup

See full code here.

Overview

It is very similar to wasmlink/demo. The difference is that the host application runs the wasmtime engine directly, so running the app is simply cargo run.

• There is a .wit file used by the host app and the "plugin" (markdown).
• The plugin uses wit_bindgen_rust::export!("../renderer.wit"); to implement the "plugin API".
• The host app uses wit_bindgen_wasmtime::import!("../renderer.wit");.

Host app details

This is how I set up a plugin, so that I can call the functions in the app.

use wasmtime::*;
use wasmtime_wasi::{WasiCtx, WasiCtxBuilder};

wit_bindgen_wasmtime::import!("../renderer.wit");
use renderer::*;

fn setup() -> anyhow::Result<(
    Store<(WasiCtx, RendererData)>,
    Renderer<(WasiCtx, RendererData)>,
)> {
    // Setup wasmtime runtime
    let engine = Engine::default();
    let module = Module::from_file(&engine, "plugins/markdown.wasm")?;

    // Our instantiation is not trivial, as we use the `.wit` file,
    // so we need to use a Linker.
    let mut linker = Linker::new(&engine);
    // In the linker, we have to add support for Wasi, as it is used by the plugin.
    wasmtime_wasi::add_to_linker(&mut linker, |(wasi, _plugin_data)| wasi)?;
    // Create a Wasi context.
    let wasi = WasiCtxBuilder::new()
        .inherit_stdio()
        .inherit_args()?
        .build();
    // In our case, there is no host data we want the plugin to modify,
    // so we pass nothing, represented by: `app_public::PluginData`...
    // But we also have to pass the wasi context just created.
    let mut store = Store::new(&engine, (wasi, renderer::RendererData {}));

    let (plugin, _instance) =
        Renderer::instantiate(&mut store, &module, &mut linker, |(_wasi, plugin_data)| {
            plugin_data
        })?;

    Ok((store, plugin))
}

[alexcrichton]

When the wit-bindgen-rust crate is linked into the final wasm module it contains the canonical abi intrinsics, located here

[saona-raimundo]

Perfect!

Now I know what happened now!

Steps to reproduce what happened to me

• Replace the macro wit_bindgen_rust::export!("../renderer.wit"); by its extension (say, from the cli)
• Drop teh dependence wit-bindgen-rust from your Cargo.toml
• Build targeting wasm32-wasi

At the end, the generated .wasm does not contain the canonical abi intrinsics!

(Maybe it is obvious foru you from the beginning...)

On code repetition

(I can start a new issue for this one, I am asking here just to know if it is worth it)
By design, the canonical abi intrinsics are packed into the wasm file that uses it. If there were many wasm modules, each of them will have the same canonical abi intrinsics.

Would it not be better if the runtime is the one responsible to contain the canonical abi intrinsics?

This design already happens with wasi: one needs to link wasi to the the runtime. Wasi functions are not packed within every wasm module.

[alexcrichton]

For an issue about the definition of canonical_abi_free I'd recomend opening an issue at https://github.com/WebAssembly/interface-types

[nitishm]

I am really sorry, I thought I had understood what was going on, but it seems I did not.

Using the macros in the wit-bindgen-{rust,wasmtime} crates works like a charm. I simply started again from the demo in wasmlink and it worked.

So... just for curiosity, in which step are the canonical_abi_* functions included?

In case it is needed, this is my setup
See full code here.

Overview

It is very similar to wasmlink/demo. The difference is that the host application runs the wasmtime engine directly, so running the app is simply cargo run.

• There is a .wit file used by the host app and the "plugin" (markdown).
• The plugin uses wit_bindgen_rust::export!("../renderer.wit"); to implement the "plugin API".
• The host app uses wit_bindgen_wasmtime::import!("../renderer.wit");.

Host app details

This is how I set up a plugin, so that I can call the functions in the app.

use wasmtime::*;
use wasmtime_wasi::{WasiCtx, WasiCtxBuilder};

wit_bindgen_wasmtime::import!("../renderer.wit");
use renderer::*;

fn setup() -> anyhow::Result<(
    Store<(WasiCtx, RendererData)>,
    Renderer<(WasiCtx, RendererData)>,
)> {
    // Setup wasmtime runtime
    let engine = Engine::default();
    let module = Module::from_file(&engine, "plugins/markdown.wasm")?;

    // Our instantiation is not trivial, as we use the `.wit` file,
    // so we need to use a Linker.
    let mut linker = Linker::new(&engine);
    // In the linker, we have to add support for Wasi, as it is used by the plugin.
    wasmtime_wasi::add_to_linker(&mut linker, |(wasi, _plugin_data)| wasi)?;
    // Create a Wasi context.
    let wasi = WasiCtxBuilder::new()
        .inherit_stdio()
        .inherit_args()?
        .build();
    // In our case, there is no host data we want the plugin to modify,
    // so we pass nothing, represented by: `app_public::PluginData`...
    // But we also have to pass the wasi context just created.
    let mut store = Store::new(&engine, (wasi, renderer::RendererData {}));

    let (plugin, _instance) =
        Renderer::instantiate(&mut store, &module, &mut linker, |(_wasi, plugin_data)| {
            plugin_data
        })?;

    Ok((store, plugin))
}

@alexcrichton it would be pretty helpful to have an example of wit-bindgen-wasmtime in the repo. I can add a simple hello-world (or markdown/rendered) example to an examples dir?

[alexcrichton]

I agree that examples would be great to have. I'd ideally like to design a format where it's easy to add examples for multiple languages, however. We can probably add language-specific ones for the time being but I'd prefer to not go too far down that route and ensure parity amongst the generators over time.

[nitishm]

I just realized @saona-raimundo provided a link to a repo where he has the complete example. @saona-raimundo would you want to check this in or if you want I can add it to the repo.

[saona-raimundo]

Sorry for the late reply! I am happy to add it as an example. I will do a PR for adding it in the wit-bindgen-wasmtime crate.