wasmtime / PR #12575 miri: add guest-debugging, including... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #12575 miri: add guest-debugging, including...

Wasmtime GitHub notifications bot (Feb 11 2026 at 23:33):

cfallin opened PR #12575 from cfallin:debug-frames-miri to bytecodealliance:main:

The fix to vm_store_context provenance in record_unwind/unwind is a little weird to me. I was seeing mut access to the vm_store_context via store.vm_store_context_mut() in record_unwind (before this diff) then access via the previously saved raw pointer in the CallThreadState, which was registered as invalid and I believe is indeed invalid. This was only manifesting when setting Config::guest_debug, even without the frame-handle accesses added here. I didn't dig into the exact diff in codegen or runtime behavior that caused this but in any case, accessing vm_store_context via these two different paths (with one mut) appears to be unsound in any case. The fix here is to set the unwind state via the raw pointer in CallThreadState since that's the only path that the subsequent unwind has access to.

Unrelated but useful: ci/miri-provenance.test.sh now accepts MIRI_RUST_VERSION=+nightly or whatnot, which is nice for running locally (I keep stable as my default toolchain).

Stacked on top of #12566 (only last commit is new).

Wasmtime GitHub notifications bot (Feb 11 2026 at 23:33):

cfallin requested alexcrichton for a review on PR #12575.

Wasmtime GitHub notifications bot (Feb 11 2026 at 23:34):

cfallin requested wasmtime-compiler-reviewers for a review on PR #12575.

Wasmtime GitHub notifications bot (Feb 11 2026 at 23:34):

cfallin requested wasmtime-default-reviewers for a review on PR #12575.

Wasmtime GitHub notifications bot (Feb 11 2026 at 23:34):

cfallin requested wasmtime-core-reviewers for a review on PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 00:07):

cfallin updated PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 00:07):

cfallin edited PR #12575:

The fix to vm_store_context provenance in record_unwind/unwind is a little weird to me. I was seeing mut access to the vm_store_context via store.vm_store_context_mut() in record_unwind (before this diff) then access via the previously saved raw pointer in the CallThreadState, which was registered as invalid and I believe is indeed invalid. This was only manifesting when setting Config::guest_debug, even without the frame-handle accesses added here. I didn't dig into the exact diff in codegen or runtime behavior that caused this but in any case, accessing vm_store_context via these two different paths (with one mut) appears to be unsound in any case. The fix here is to set the unwind state via the raw pointer in CallThreadState since that's the only path that the subsequent unwind has access to.

Unrelated but useful: ci/miri-provenance.test.sh now accepts MIRI_RUST_VERSION=+nightly or whatnot, which is nice for running locally (I keep stable as my default toolchain).

Wasmtime GitHub notifications bot (Feb 12 2026 at 00:08):

cfallin updated PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 00:09):

cfallin updated PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 01:40):

alexcrichton submitted PR review:

Thanks! Do you think it'd be worth running through anything else in the debug API as well? Or does getting a module more-or-less exercise everything?

Wasmtime GitHub notifications bot (Feb 12 2026 at 01:40):

alexcrichton created PR review comment:

Another way you can run this script is rustup run nightly ./ci/miri-provenance.test.sh ... although using MIRI_RUST_VERSION=+nightly works here too just as well

Wasmtime GitHub notifications bot (Feb 12 2026 at 04:29):

github-actions[bot] added the label wasmtime:api on PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 05:02):

cfallin updated PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 05:02):

cfallin submitted PR review.

Wasmtime GitHub notifications bot (Feb 12 2026 at 05:02):

cfallin created PR review comment:

Ah, I had no idea -- thanks! Removed my ad-hoc env var and added a comment to this script instead noting this trick.

Wasmtime GitHub notifications bot (Feb 12 2026 at 05:03):

cfallin commented on PR #12575:

Getting the current module exercises almost everything (frame-walking, getting metadata, reading raw vmctx and converting back to proper borrow of instance, etc) but I added a few more reads for good measure. Thanks!

Wasmtime GitHub notifications bot (Feb 12 2026 at 05:03):

cfallin has enabled auto merge for PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 05:15):

cfallin added PR #12575 miri: add guest-debugging, including frame accesses. to the merge queue

Wasmtime GitHub notifications bot (Feb 12 2026 at 05:18):

cfallin edited PR #12575:

The fix to vm_store_context provenance in record_unwind/unwind is a little weird to me. I was seeing mut access to the vm_store_context via store.vm_store_context_mut() in record_unwind (before this diff) then access via the previously saved raw pointer in the CallThreadState, which was registered as invalid and I believe is indeed invalid. This was only manifesting when setting Config::guest_debug, even without the frame-handle accesses added here. I didn't dig into the exact diff in codegen or runtime behavior that caused this but in any case, accessing vm_store_context via these two different paths (with one mut) appears to be unsound in any case. The fix here is to set the unwind state via the raw pointer in CallThreadState since that's the only path that the subsequent unwind has access to.

Wasmtime GitHub notifications bot (Feb 12 2026 at 05:41):

github-merge-queue[bot] removed PR #12575 miri: add guest-debugging, including frame accesses. from the merge queue

Wasmtime GitHub notifications bot (Feb 12 2026 at 18:14):

cfallin updated PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 18:16):

cfallin commented on PR #12575:

@alexcrichton pinging for re-review here -- another miri test failure (not part of the Pulley provenance test) has pushed me back toward another approach that involves re-deriving the raw VMStoreContext pointer in CallThreadState when setting up unwind state, for provenance reasons; this avoids action-at-a-distance failures where any mutation on the store in some path can potentially invalidate provenance.

Wasmtime GitHub notifications bot (Feb 12 2026 at 18:16):

cfallin updated PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 18:18):

cfallin updated PR #12575.

Wasmtime GitHub notifications bot (Feb 12 2026 at 18:57):

cfallin commented on PR #12575:

(There's still a failure on s390x only that I suspect is an endianness issue when running Pulley + guest-debug instrumentation -- will take a look)

Wasmtime GitHub notifications bot (Feb 12 2026 at 19:44):

alexcrichton submitted PR review:

Looks reasonable to me yeah :+1:

Wasmtime GitHub notifications bot (Feb 12 2026 at 19:47):

cfallin commented on PR #12575:

A little more detail: Pulley on s390x with guest-debug enabled (which hasn't been tested before -- only native s390x with guest-debug) is generating a big-endian vector store in the CLIF to compile to Pulley, which Cranelift's Pulley backend doesn't support. That's a nontrivial bit of implementation (lane swapping, etc). I'll instead refactor the instrumentation to work as e.g. object fields do, always little endian, in a separate PR.