Adrian Ibanez (Mar 17 2025 at 06:31): Adrian Ibanez (Mar 17 2025 at 06:31):Hi. I'm quite new to wasm and currently integrating a wasm runtime based on wasmtime ( wasmex ). I played around with some simple examples. Also tried to integrate edge impulse webassembly modules. but without any luck so far.
example-standalone-inferencing-wasm % wasmtime run ~/Downloads/tutorial_-continuous-motion-recognition-wasm-v59/browser/edge-impulse-standalone.wasm
Error: failed to run main module /Users/adrianibanez/Downloads/tutorial_-continuous-motion-recognition-wasm-v59/browser/edge-impulse-standalone.wasm
Caused by:
0: failed to instantiate "/Users/adrianibanez/Downloads/tutorial_-continuous-motion-recognition-wasm-v59/browser/edge-impulse-standalone.wasm"
1: unknown import: env::abort has not been defined
Posted a question about wasmtime in their community forum for additional information.
I was wondering if someone could point me to information about "example" wasm files with some degree of complexity. I'm particularly interested in how a wasmtime host can identify and encode / decode available functions. Is there some kind of "manifest" / description file? How are nontrivial wasm modules deployed into the wild?
My goal would be to support downloadable wasm packages. And I need some way of looking up metadata about those packages including versioning.
infos about edge impulse module: https://github.com/tessi/wasmex/issues/743
Adrian Ibanez (Mar 17 2025 at 07:09):Ok, I made some progress. Maybe a bit too lowlevel for a first integration attempt ;) They put so much abstraction into the javascript that the wasm part became almost "unusable". Does anyone have experience with such setups?
Is there a strategy to get such kind of wasm modules running in a environment like wasmtime. Eg. convert the javascript into wasm and use 2 wasm modules that communicate with each other? ... asking this with blissful ignorance ;)
%{
"__dl_seterr" => {:fn, [:i32, :i32], []},
"__embind_register_native_and_builtin_types" => {:fn, [], []},
"__errno_location" => {:fn, [], [:i32]},
"__getTypeName" => {:fn, [:i32], [:i32]},
"__indirect_function_table" => {:table,
%{maximum: 1723, type: {:reference, "(ref null func)"}, minimum: 1723}},
"__stdio_exit" => {:fn, [], []},
"__wasm_call_ctors" => {:fn, [], []},
"dynCall_iiiijj" => {:fn, [:i32, :i32, :i32, :i32, :i32, :i32, :i32, :i32],
[:i32]},
"dynCall_jiji" => {:fn, [:i32, :i32, :i32, :i32, :i32], [:i32]},
"dynCall_jjj" => {:fn, [:i32, :i32, :i32, :i32, :i32], [:i32]},
"dynCall_viiijjj" => {:fn,
[:i32, :i32, :i32, :i32, :i32, :i32, :i32, :i32, :i32, :i32], []},
"dynCall_viijj" => {:fn, [:i32, :i32, :i32, :i32, :i32, :i32, :i32], []},
"emscripten_builtin_memalign" => {:fn, [:i32, :i32], [:i32]},
"emscripten_stack_get_base" => {:fn, [], [:i32]},
"emscripten_stack_get_end" => {:fn, [], [:i32]},
"emscripten_stack_get_free" => {:fn, [], [:i32]},
"emscripten_stack_init" => {:fn, [], []},
"free" => {:fn, [:i32], []},
"malloc" => {:fn, [:i32], [:i32]},
"memory" => {:memory,
%{maximum: 32768, shared: false, memory64: false, minimum: 2048}},
"stackAlloc" => {:fn, [:i32], [:i32]},
"stackRestore" => {:fn, [:i32], []},
"stackSave" => {:fn, [], [:i32]}
}
It's 268K of javascript and a 6.5MB wasm file
bjorn3 (Mar 17 2025 at 08:33):I think the wasm module was compiled with Emscripten. Wasmtime doesn't support the Emscripten ABI. Try building it with wasi-sdk instead.
Adrian Ibanez (Mar 17 2025 at 10:03):I have no control over the wasm / js library. it is provided as one of the deployment targets of edge impulse models. they support numerous hardware, c++ libs, ...
would compiling the c++ sourcecode to wasm be a more feasible strategy to deploy as wasm for wasmtime runtime?
Adrian Ibanez (Mar 17 2025 at 11:53):What about pglite wasm? Do the exports and specially the imports look like something that could be supported in a wasmtime runtime? Appologies if I'm asking very basic or silly questions; just starting to build an understanding of the contraints and dependencies within the wasm ecosystem.
infos-pglite-functions.txt
Adrian Ibanez (Mar 17 2025 at 11:54):I'm particularly interested in understanding what kind of system calls are available by default in wasmtime.
eg. wasi_snapshot_preview1" => %{
"clock_time_get" => {:fn, [:i32, :i64, :i32], [:i32]},
"environ_get" => {:fn, [:i32, :i32], [:i32]},
"environ_sizes_get" => {:fn, [:i32, :i32], [:i32]},
"fd_close" => {:fn, [:i32], [:i32]},
"fd_fdstat_get" => {:fn, [:i32, :i32], [:i32]},
"fd_pread" => {:fn, [:i32, :i32, :i32, :i64, :i32], [:i32]},
"fd_pwrite" => {:fn, [:i32, :i32, :i32, :i64, :i32], [:i32]},
"fd_read" => {:fn, [:i32, :i32, :i32, :i32], [:i32]},
"fd_seek" => {:fn, [:i32, :i64, :i32, :i32], [:i32]},
"fd_sync" => {:fn, [:i32], [:i32]},
"fd_write" => {:fn, [:i32, :i32, :i32, :i32], [:i32]},
"proc_exit" => {:fn, [:i32], []}
}
bjorn3 (Mar 17 2025 at 12:27):Yes, wasip1 (which uses the wasi_snapshot_preview1 module) is supported by Wasmtime.
bjorn3 (Mar 17 2025 at 12:28):Wasmtime has wasip1 and wasip2 support builtin. Any other ABI is not supported by the cli, but could be implemented yourself when using wasmtime as library.
Adrian Ibanez (Mar 17 2025 at 12:45):have just been talking to the pglite developers. they are working on a implementation that will definitely run on wasmtime. "We use emscripten to build the version used in the npm package. And we have an in development "libpglite.wasm" that compiles it with the wasm sdk - this has the lower level api, and is geared towards wasm runtimes that are not inside a JS runtime."
Last updated: Apr 08 2025 at 12:05 UTC