Stream: git-wasmtime

Topic: wasmtime / issue #11486 Exceptions: support Pulley

Wasmtime GitHub notifications bot (Aug 21 2025 at 02:17):

cfallin opened issue #11486:

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

Wasmtime GitHub notifications bot (Aug 21 2025 at 02:17):

cfallin added the pulley label to Issue #11486.

Wasmtime GitHub notifications bot (Aug 21 2025 at 02:17):

cfallin added the wasm-proposal:exceptions label to Issue #11486.

Wasmtime GitHub notifications bot (Aug 21 2025 at 02:17):

github-actions[bot] commented on issue #11486:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "pulley"

Thus the following users have been cc'd because of the following labels:

• fitzgen: pulley

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Aug 21 2025 at 22:42):

alexcrichton closed issue #11486:

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

Last updated: Dec 06 2025 at 07:03 UTC