Reproduction
Wasmtime's built-in guest-debug gdbstub does not expose a shared linear memory in its synthetic address space. This prevents LLDB from reading globals and runtime-backed values even though source breakpoints, Wasm locals, and backtraces work.
main.wat:
(module
(memory (export "memory") 1 1 shared)
(func $entry (export "_start")
i32.const 0
i32.const 42
i32.store
unreachable))Build and start guest debugging:
wat2wasm --debug-names --enable-threads main.wat -o main.wasm
wasmtime run -g 1234 -W threads=y,shared-memory=y main.wasm
Using a Wasm-aware LLDB:
(lldb) target create main.wasm
(lldb) process connect --plugin wasm connect://127.0.0.1:1234
(lldb) continue
# stopped at the final `unreachable`, after storing 42
(lldb) process plugin packet send qXfer:memory-map:read::0,ffff
response: ...<memory-map><memory type="rom" start="0x4000000000000000" length="0x51"/></memory-map>
(lldb) memory read --size 4 --format decimal --count 1 0x0
error: memory read failed for 0x0
The equivalent unshared memory is reported as a ram region at address 0 and can be read successfully.
Expected result
The shared memory should appear in the RSP memory map and support reads while the guest is stopped, just like an unshared memory. Guest source-language adapters need this to inspect globals and runtime values.
Likely cause
Instance::debug_memory intentionally returns only unshared Memory and directs callers to debug_shared_memory for shared memory:
https://github.com/bytecodealliance/wasmtime/blob/v47.0.3/crates/wasmtime/src/runtime/debug.rs#L202-L247
However, the debugger host API's instance_get_memory only calls debug_memory:
https://github.com/bytecodealliance/wasmtime/blob/v47.0.3/crates/debugger/src/host/opaque.rs#L166-L173
The gdbstub address-space implementation consequently has no shared-memory resource to enumerate:
https://github.com/bytecodealliance/wasmtime/blob/v47.0.3/crates/gdbstub-component/src/addr.rs#L60-L78
It looks like the debugger resource abstraction needs to represent both Memory and SharedMemory, then implement size/read/write operations for both.
Environment
- Wasmtime 47.0.3 (
5554cc1a6, 2026-07-31); the same behavior was also observed with 44.0.0
- wasi-sdk 33 LLDB 22.1.0 with the Wasm process plugin
- macOS arm64
This was found while implementing WASI source debugging for xgo-dev/llgo#2164, but the WAT reproduction is independent of LLGo.
Reproduction
Wasmtime's built-in guest-debug gdbstub does not expose a shared linear memory in its synthetic address space. This prevents LLDB from reading globals and runtime-backed values even though source breakpoints, Wasm locals, and backtraces work.
main.wat:Build and start guest debugging:
Using a Wasm-aware LLDB:
The equivalent unshared memory is reported as a
ramregion at address 0 and can be read successfully.Expected result
The shared memory should appear in the RSP memory map and support reads while the guest is stopped, just like an unshared memory. Guest source-language adapters need this to inspect globals and runtime values.
Likely cause
Instance::debug_memoryintentionally returns only unsharedMemoryand directs callers todebug_shared_memoryfor shared memory:https://github.com/bytecodealliance/wasmtime/blob/v47.0.3/crates/wasmtime/src/runtime/debug.rs#L202-L247
However, the debugger host API's
instance_get_memoryonly callsdebug_memory:https://github.com/bytecodealliance/wasmtime/blob/v47.0.3/crates/debugger/src/host/opaque.rs#L166-L173
The gdbstub address-space implementation consequently has no shared-memory resource to enumerate:
https://github.com/bytecodealliance/wasmtime/blob/v47.0.3/crates/gdbstub-component/src/addr.rs#L60-L78
It looks like the debugger resource abstraction needs to represent both
MemoryandSharedMemory, then implement size/read/write operations for both.Environment
5554cc1a6, 2026-07-31); the same behavior was also observed with 44.0.0This was found while implementing WASI source debugging for xgo-dev/llgo#2164, but the WAT reproduction is independent of LLGo.