Stream: git-wasmtime

Topic: wasmtime / PR #12997 aarch64: Support exception handling ...

Wasmtime GitHub notifications bot (Apr 09 2026 at 13:01):

DePasqualeOrg opened PR #12997 from DePasqualeOrg:aarch64-apple-exception-handling to bytecodealliance:main:

This PR adds AppleAarch64 to the exception handling code paths in the Cranelift backend so that Wasm modules using the exception handling proposal can be compiled on Apple AArch64 targets.

Problem

When compiling a Wasm module that uses the exception handling proposal (e.g., CPython compiled to WASI) with the AppleAarch64 calling convention, Cranelift panics:

unimplemented clobbers for exn abi of AppleAarch64

and

assertion `left == right` failed: left: 0, right: 2

This is because AppleAarch64 is missing from four match arms in the Cranelift backend. Without the fix, AppleAarch64 exception handling is either rejected by the verifier or panics later in lowering, depending on the pipeline:

1. supports_exceptions: returns false, causing the verifier to reject try_call with apple_aarch64 callees
2. get_regs_clobbered_by_call: falls through to the (_, true) => panic!(...) arm for exception calls
3. exception_payload_regs: falls through to _ => &[], returning no payload registers
4. exception_payload_types: falls through to _ => &[], returning no payload types

The AppleAarch64 calling convention uses the same AAPCS general-purpose register layout as SystemV for exception handling purposes (x0–x7 for arguments, same caller-saved set), though it differs in other aspects such as argument extension behavior.

Changes

cranelift/codegen/src/isa/call_conv.rs

Add AppleAarch64 alongside SystemV in:

• supports_exceptions: returns true so the verifier accepts try_call with apple_aarch64 callees
• exception_payload_types: returns [I64, I64] (or [I32, I32] for 32-bit) as payload types

cranelift/codegen/src/isa/aarch64/abi.rs

Add AppleAarch64 alongside SystemV in:

• get_regs_clobbered_by_call: uses DEFAULT_AAPCS_CLOBBERS for both normal and exception calls
• exception_payload_regs: returns [x0, x1] as payload registers

cranelift/filetests/filetests/isa/aarch64/exceptions-apple-aarch64.clif

Add a compile-only filetest that exercises try_call and try_call_indirect with the apple_aarch64 calling convention, to prevent regressions.

Testing

Validated by compiling and running CPython (from the Wasmer Registry's python/python package) on macOS aarch64. Without the fix, compilation panics. With the fix, python -c "print('hello')" runs successfully.

Also validated that existing tools using simpler exception handling (grep, sed) continue to work.

Wasmtime GitHub notifications bot (Apr 09 2026 at 13:01):

DePasqualeOrg requested fitzgen for a review on PR #12997.

Wasmtime GitHub notifications bot (Apr 09 2026 at 13:01):

DePasqualeOrg requested wasmtime-compiler-reviewers for a review on PR #12997.

Wasmtime GitHub notifications bot (Apr 09 2026 at 13:51):

cfallin commented on PR #12997:

@DePasqualeOrg thanks for the PR. Could you clarify how you ran into this issue? At a high level, Wasmtime supports exception-handling on macOS just fine; this works because Wasm modules' functions are compiled using our internal calling convention (tail) so we don't actually need exception-handling in the system ABI. We avoided that because it comes with other pitfalls, e.g. the need to restore clobbers at every frame using unwind info in the unwinder as well.

So when you say

When compiling a Wasm module that uses the exception handling proposal (e.g., CPython compiled to WASI) with the AppleAarch64 calling convention, Cranelift panics:

How are you compiling a Wasm module in a way that requires this?

Wasmtime GitHub notifications bot (Apr 09 2026 at 14:56):

DePasqualeOrg closed without merge PR #12997.

Wasmtime GitHub notifications bot (Apr 09 2026 at 14:56):

DePasqualeOrg commented on PR #12997:

Sorry, I should have tried to reproduce this before submitting. Whatever crash I was encountering happened a week ago, and I documented it then, but something must have changed since then, and I must not have documented it correctly. I'll close this for now.

Wasmtime GitHub notifications bot (Apr 09 2026 at 14:59):

cfallin commented on PR #12997:

No worries; thanks. I'm still curious what your overall workflow is: did you encounter this issue in Wasmtime running a Wasm module? We'd like to know if so.

Wasmtime GitHub notifications bot (Apr 09 2026 at 15:21):

DePasqualeOrg commented on PR #12997:

I'm building a Swift library that uses the Wasmtime C API to run WASI tools (coreutils, sed, jq, Python, etc.) on macOS and iOS. On macOS it uses Cranelift JIT, and on iOS it targets Pulley.

Wasmtime GitHub notifications bot (Apr 09 2026 at 15:38):

cfallin commented on PR #12997:

That's very odd then. As noted above, Wasmtime doesn't use the system ABI to compile exceptions internally, and is extensively tested (including with exceptions) on macOS. If you have any documentation on how you hit an error, please do file a detailed issue.

Last updated: Apr 12 2026 at 23:10 UTC