Stream: git-wasmtime

Topic: wasmtime / PR #13259 Unwinder arm64 32 asm format


view this post on Zulip Wasmtime GitHub notifications bot (May 04 2026 at 03:51):

matthargett opened PR #13259 from rebeckerspecialties:unwinder-arm64_32-asm-format to bytecodealliance:main:

Two-commit series enabling wasmtime to build for arm64_32-apple-watchos
(Apple Watch Series 4+ ILP32 ABI). Verified end-to-end on a real Apple
Watch SE 2 (S8 SoC, watchOS 11.6.2) running an 11-workload Pulley
benchmark.

Commit 1 — \`unwinder: explicit 64-bit register view in aarch64 inline asm for arm64_32\`

\`crates/unwinder/src/arch/aarch64.rs\` has two inline-asm blocks that
operate on a \`usize\`-typed register placeholder. On aarch64 \`usize\` is
u64 and the implicit register format (\`x<N>\`) is unambiguous and
correct. On arm64_32 (Apple Watch S4+, ILP32 ABI: 64-bit registers,
32-bit pointers), \`usize\` is u32 and the formatter is ambiguous between
\`w<N>\` (32-bit lane) and \`x<N>\` (64-bit GPR view) — exactly what
rustc's \`asm_sub_register\` lint flags. There's also a real correctness
hazard: unwinder code that handles a return address would have a
32-bit value in a 64-bit GPR, and the wrong format spec could insert a
sub-register move that drops the upper bits at the wrong moment.

\`lr\` and \`sp\` are 64-bit-only — there is no addressable 32-bit alias
of either, so the only valid register view in the specific \`mov\`
instructions used here is \`x\`. Lock that in explicitly via \`{0:x}\`
and \`{pc:x}\`. The compiler zero-extends u32 → x<N> on the way in and
truncates x<N> → u32 on the way out automatically; \`xpaclri\`
operates on the full LR as before.

No behavior change on aarch64; silences two \`asm_sub_register\` warnings
on arm64_32-apple-watchos.

Commit 2 — \`Bump mach2 dep from 0.4.2 to 0.6\`

\`mach2 v0.4.2\` emits \`compile_error!(\"mach requires macOS or iOS\")\`
on any target where neither \`target_os = \"macos\"\` nor \`ios\` matches,
plus a matching narrow \`target_vendor\` gate on its \`libc\` build-dep.
That blocks Apple watchOS / tvOS / visionOS targets — wasmtime's
\`runtime\` feature pulls \`mach2\` in unconditionally so the build fails
with both \`error: mach requires macOS or iOS\` and
\`error[E0463]: can't find crate for libc\`.

The fix has been upstream in mach2 since 0.6.0 (commit \`538ce75\`,
2025-08-16, \"Add support for tvOS, watchOS and visionOS\"): both gates
widen to \`cfg(target_vendor = \"apple\")\`. The mach2 module API
wasmtime imports
(\`exc\`, \`exception_types\`, \`kern_return\`, \`mach_init\`, \`mach_port\`,
\`message\`, \`ndr\`, \`port\`, \`thread_act\`, \`thread_status\`) is
unchanged between 0.4.2 and 0.6.0; only internal libc/core::ffi
type-plumbing differs. Bumping the workspace dep is sufficient — no
changes in \`machports.rs\`.

Verified by building \`wasmtime\` as a \`staticlib\` for
\`arm64_32-apple-watchos\` under
\`nightly-2026-01-25 + -Z build-std=std,panic_abort\` with
\`--features pulley,runtime,std,cranelift,anyhow\`. The dev-only path
(\`cranelift-jit -> region -> mach2 0.4.x\`) keeps an older mach2 in the
lockfile for cranelift-jit's own host tests; that path is not part of
any production embedder build and stays unchanged.

End-to-end verification

This 2-commit stack + the companion target-lexicon \`Arm64_32\` patch
(submitted separately to bytecodealliance/target-lexicon) is enough to
build a Pulley-only static library for arm64_32-apple-watchos and link
it into a watchOS app. On real hardware (Apple Watch SE 2, S8 SoC):

workload run-time on SE 2
fib(30) 125.33 ms
fib_tail(100000) [return_call] 0.566 ms
sieve(10000) 0.763 ms
crc32(64 KiB) 5.288 ms
matmul simd128 64×64 4.079 ms
matmul relaxed-simd FMA 3.242 ms
convolution 256×256 10.83 ms
audio DSP 1000 frames × 512 1463.99 ms
bulk_memory (memory.copy/fill) 30.69 ms
call_indirect (200 K dispatches) 36.45 ms

All results match the host-Rust reference function byte-for-byte.

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2026 at 03:51):

matthargett requested dicej for a review on PR #13259.

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2026 at 03:51):

matthargett requested wasmtime-core-reviewers for a review on PR #13259.

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2026 at 03:51):

matthargett requested wasmtime-default-reviewers for a review on PR #13259.


Last updated: Jun 01 2026 at 09:49 UTC