wasmtime status plz : functional or not ?
(don't personally need it right now - someone on another board asked)
Do you mean wasm traps (work), the wasm exceptions proposal (no implementations anywhere AFAIK), panics from inside rust functions provided to the wasm code (work) or C++ exceptions when compiling to wasm (emscripten has a pass to turn them into mvp wasm code, so no engine support necessary in that case, emscripten doesn't work in wasmtime though) or something else?
I mean this on mozilla web assembly group : https://matrix.to/#/!KoNjfbMUbtwPSBcKlx:mozilla.org/$eKZr2a4teGWVUC6qFFuVWuruuAzbYW-vDXrR0RtYGwc?via=mozilla.org&via=igalia.com&via=matrix.org
shouldn't get involved, not my current issue. but fyi. he asked if wasmtime supports exceptions & I don't know.
unsure if that link is valid, https://chat.mozilla.org/#/room/#webassembly:mozilla.org
jmux posts, just above my lldbg stuff.
Replied over on Matrix; the answer is, unfortunately, that we don't support Wasm exception handling in Wasmtime yet
At some point we should but it's not being actively worked on by anyone (AFAIK)
we do have exceptions support in wasmparser
/wasm-encoder
/wasm-smith
/etc. fwiw so it is "just" a matter of implementing support in wasmtime (and cranelift)
to complete my tangent, if he really must do something wasm with exceptions right now, emscripten is the way ?
apparently not. its a toolchain, not a runtime.
https://emscripten.org/docs/porting/exceptions.html
For now I can use Emscripten's "JavaScript-based exception" handling. LibreOffice (LO) uses exceptions + threads. My build with -fwasm-exceptions failed, because the libpng + libjpeg based image decoders use setjmp + longjmp (patches tagged with SjLj in LLVM), which isn't supported by LLVM. Otherwise I have a LO demo app running in the browser (vcldemo), but that just tests the graphics backend. Still need to find a way to figure out dynamic function calls based on some mangled data, probably using call_indirect somehow. I've read somewhere, that WASM function tables + function typedef are dynamic, so eventually I can generate the entries on demand. On other platforms it uses assembler to prepare the needed registers with the systems call convention and eventual some trampoline code.
It's been a long time since there was a conversation here. I'm pleased to report that we are working on adding Exception handling support to WAMR (not Wasmtime currently). There is a Github issue we are using to track this, you can find it here : https://github.com/bytecodealliance/wasm-micro-runtime/issues/1884
Please feel free to comment.
At the moment we've working through an implementation just for WAMR's interpreter, so not JIT / AOT support, at least initially.
We do have compatibility concerns, and would like to reach out to the browser teams to ensure that replicate whatever compliance that was completed between Spidermonkey and V8 to ensure exception handling worked between both teams, and of course to understand how the emscripten folk modified the clang++ tool chain to support WASM's exceptions..... some more learning to do, but we are making progress at the moment.
For the record I'm going to work on adding exception support to Cranelift for my bachlor thesis.
Is there any non -browser runtime that support wasm exceptions yet?
https://webassembly.org/roadmap/ only if you count wasm2c.
Wasmtime does not: https://github.com/bytecodealliance/wasmtime/blob/main/docs/stability-wasm-proposals-support.md
I scanned wamr and did not find mentions of the proposal there: https://github.com/bytecodealliance/wasm-micro-runtime/blob/a2d4744a2b2c587eacca66c357dc2e88925fcadd/RELEASE_NOTES.md
Thanks, I guess there is node/v8 depending if you count that as browser. Runs from the CLI so it is available where the other runtimes are generally at least.
I'm currently working on adding exception support to Cranelift for my bachelor thesis.
Awesome, good luck and look forward to seeing it
Thanks!
Status update: Got exception handling working with cg_clif. Currently working on implementing it for wasmtime.
Last updated: Nov 22 2024 at 17:03 UTC