The exception-handling support as implemented in #11326 does not yet support Pulley. It is almost there, but not quite:
- Pulley's use of Cranelift for code generation means that we do get exception metadata alongside Pulley bytecode, and a module that uses exceptions can be compiled;
- The support for stack-walking of Pulley stacks means that the exception unwinder can find handlers in Pulley code;
- However, the
raise libcall implementation that Pulley uses does not account for UnwindState::UnwindToWasm. This means that we'll reach host-to-Wasm entry instead, with an unexpected unwind state, and panic.
In this comment I outline an alternative approach: we should
- invoke the real
raise libcall, just as we do other libcalls, from Pulley;
- when we enter
unwind, and either wasmtime_longjmp() or wasmtime_unwinder::resume_to_exception_handler(), we instead check the store's executor and
- on native code, do as we do today
- on Pulley, update the Pulley interpreter state appropriately
The exception-handling support as implemented in #11326 does not yet support Pulley. It is almost there, but not quite:
raiselibcall implementation that Pulley uses does not account forUnwindState::UnwindToWasm. This means that we'll reach host-to-Wasm entry instead, with an unexpected unwind state, and panic.In this comment I outline an alternative approach: we should
raiselibcall, just as we do other libcalls, from Pulley;unwind, and eitherwasmtime_longjmp()orwasmtime_unwinder::resume_to_exception_handler(), we instead check the store's executor and