How to execute a wasm (rust) function with &str input and String output? about wasmtime-dotnet HOT 3 CLOSED

Hi @aonnk. Sorry for the delay in getting back to you.

The article you linked to (which is pretty out of date this point) was using cargo wasi build to create the .wasm file rather than wasm-pack.

With cargo wasi build, I get the following function type:

(func (param i32 i32) (result i32 i32))

Whereas with wasm-pack I get the same signature as you:

(func (param i32 i32 i32))

I suspect the difference is in support of the multi-value proposal. As I've never really used wasm-pack, perhaps @alexcrichton might know how cargo wasi build gets multi-value enabled whereas the latest wasm-pack does not.

At any rate, if you look at the wrapping function in the glue code, you'll get some context on what the first parameter to the Wasm export is:

export function makesha256(s) {
    try {
        const retptr = wasm.__wbindgen_export_0.value - 16;
        wasm.__wbindgen_export_0.value = retptr;
        var ptr0 = passStringToWasm0(s, wasm.__wbindgen_malloc, wasm.__wbindgen_realloc);
        var len0 = WASM_VECTOR_LEN;
        wasm.makesha256(retptr, ptr0, len0);
        var r0 = getInt32Memory0()[retptr / 4 + 0];
        var r1 = getInt32Memory0()[retptr / 4 + 1];
        return getStringFromWasm0(r0, r1);
    } finally {
        wasm.__wbindgen_export_0.value += 16;
        wasm.__wbindgen_free(r0, r1);
    }
}

The first parameter is actually the return value, which is expected to be a pointer to 8 bytes (4 bytes for the ptr and 4 bytes for the length).

Here the function is allocating 16 bytes of "stack" via __wbindgen_export_0 (I believe the wasm program is expecting a 16-byte alignment), passing in the stack address as the first argument, calling the function, reading the return string out of the memory, and then calling __wbindgen_free to free the returned string in the wasm program.

You should be able to replicate the same thing from C# using the exported stack pointer global __wbindgen_export_0.

from wasmtime-dotnet.

Ah yeah this is where wasm-pack build differs in compilation settings than cargo wasi build, namely the latter is "use interface types if you can". The former (coming out of wasm-pack build) basically uses whatever ABI for the function that wasm-bindgen expects. The proc-macro and the JS glue are kept in sync internally to ensure this all works out.

If you're using a wasm-bindgen generated wasm module then if you're trying to match the ABI as @peterhuene says the JS glue can give you hints as to what's going on, but otherwise it's a pretty internal thing of wasm-bindgen and isn't guaranteed to be the same across versions.

from wasmtime-dotnet.

Hi @aonnk:

Please let us know if the above information doesn't help you.

As this issue seems external to the .NET API, I'm going to close this issue for now.

Thanks!

from wasmtime-dotnet.