Stream: git-wasmtime

Topic: wasmtime / PR #14087 debugger: expose shared memories to ...

Wasmtime GitHub notifications bot (Aug 06 2026 at 19:57):

AlisinaDevelo opened PR #14087 from AlisinaDevelo:fix/14062-shared-memory-debugger to bytecodealliance:main:

shared linear memories were omitted from the synthetic Wasm address space; this maps both memory types, implements shared-memory access, and adds an LLDB regression test proving address 0 reads correctly.

Wasmtime GitHub notifications bot (Aug 06 2026 at 19:57):

AlisinaDevelo requested dicej for a review on PR #14087.

Wasmtime GitHub notifications bot (Aug 06 2026 at 19:57):

AlisinaDevelo requested wasmtime-core-reviewers for a review on PR #14087.

Wasmtime GitHub notifications bot (Aug 06 2026 at 20:00):

dicej commented on PR #14087:

@cfallin would you be able to take a look at this?

Wasmtime GitHub notifications bot (Aug 07 2026 at 14:15):

:repeat: cfallin submitted PR review:

Thanks for the PR. I have a number of comments below, as well as one top-level thought:

Lack of support for shared memories is downstream of the bigger issue that we don't support debugging multithreaded programs. That is because wasi-threads has an instance+store-per-thread model, and the debugger controls only one debuggee store. A good debugging experience on a multithreaded program must pause all threads, and that's what a debugger like LLDB expects. The fact that the rest-of-the-world may keep running is visible implicitly in this patch: you need to cast the *UnsafeCell<u8> representing a byte in the shared memory to an *AtomicU8 and do an atomic access to avoid UB on the access because another thread may also be mutating it. But that's a bad debug experience, violates LLDB's assumptions, and so I don't think it makes sense to expose.

Aside from all that, the gdbstub protocol has a bunch of stuff to report and control thread state; I'd expect we would want all that as well if we truly supported multithreaded debugging.

So a question: do you have a plan for those broader questions? Or if not, what is the use-case for attaching a debugger to just one thread and observing its shared memory?

Wasmtime GitHub notifications bot (Aug 07 2026 at 14:15):

:speech_balloon: cfallin created PR review comment:

This is the wrong level at which to test; it's extremely verbose and a lot of machinery to poke inside resource-tables and such.

We have an integration test that starts up Wasmtime with the gdbstub component and runs LLDB against it. Perhaps you can write a test there with a custom-in-WAT debuggee that has a shared memory, and then show that you can print its memory contents with LLDB?

Wasmtime GitHub notifications bot (Aug 07 2026 at 14:15):

:speech_balloon: cfallin created PR review comment:

No need to send a manually-written gdbstub packet (!) like this; the memory read will already verify that the memory map exposes the memory.

Wasmtime GitHub notifications bot (Aug 07 2026 at 14:15):

:speech_balloon: cfallin created PR review comment:

I'd prefer not to expose an internal pointer to the debug component like this -- it feels like an encapsulation violation. Instead we should add debug_index_in_store to SharedMemory as we did for Memory.

Wasmtime GitHub notifications bot (Aug 07 2026 at 14:15):

:speech_balloon: cfallin created PR review comment:

No need for narrative comments like this that refer to what used to be in the source -- using a batch file is a perfectly reasonable solution on its own, and this sentence is hard to parse without the context of the diff and previous state.

Wasmtime GitHub notifications bot (Aug 07 2026 at 14:15):

:speech_balloon: cfallin created PR review comment:

(On reading further, I see that you did that -- so, please just delete this whole unit test)

Wasmtime GitHub notifications bot (Aug 08 2026 at 01:57):

AlisinaDevelo updated PR #14087.

Wasmtime GitHub notifications bot (Aug 08 2026 at 02:00):

AlisinaDevelo commented on PR #14087:

Thanks @cfallin I addressed the comments. Shared memories now use a stable debugger ID, the extra unit test and manual qXfer packet are gone, and the LLDB test now reads the memory directly. Local tests pass. This only covers inspecting shared memory in the current single-store debugger; multi-store wasi-threads debugging remains separate. Thanks again fir the review.

Wasmtime GitHub notifications bot (Aug 08 2026 at 03:12):

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

Wasmtime GitHub notifications bot (Aug 10 2026 at 22:41):

cfallin commented on PR #14087:

multi-store wasi-threads debugging remains separate.

OK -- when you say "remains separate", do you mean that you have a follow-up PR, or just that you haven't solved that problem?

I ask because I am fairly concerned about exposing this otherwise: it violates the assumptions that common debuggers will make about all threads being paused and state not being mutated under one's nose. This is why I said "But that's a bad debug experience, violates LLDB's assumptions, and so I don't think it makes sense to expose."

Wasmtime GitHub notifications bot (Aug 12 2026 at 01:51):

AlisinaDevelo commented on PR #14087:

Thank you @cfallin No I don’t have a follow-up PR for the thread coordination work yet. I meant that it remains unsolved. Given your concern about shared memory changing while LLDB thinks the debuggee is stopped, should I close this PR and work on a thread-aware debugger design separately, or would a narrower first step be useful?

Wasmtime GitHub notifications bot (Aug 13 2026 at 21:36):

:memo: cfallin submitted PR review:

OK, thanks. I think it's probably fine to fill in this gap for now, as long as one understands that building a true multithreaded debugger is not fully solved by having SharedMemory support; and in particular, that it is the debug host's responsibility to "stop the world" so concurrent writes to the SharedMemory do not occur and surprise the debugger.

One nit below -- want to make sure everything is properly feature-gated. Happy to merge after that. Thanks for your patience!

Wasmtime GitHub notifications bot (Aug 13 2026 at 21:36):

:speech_balloon: cfallin created PR review comment:

Let's not unconditionally add the threads feature here -- we want to put this behavior under a threads feature on the debugger crate, make that feature depend on wasmtime/threads, and we want to ensure everything builds without the feature as well.

Last updated: Aug 30 2026 at 09:07 UTC