DWARF debug info: local variables show "no location, value may have been optimized out" in LLDB

[radu-matei]

I'm working on debugging support for WASI HTTP/Spin Rust components.
Breakpoints are correctly triggered; however, inspecting variables through LLDB/VS Code results in "no location, value may have been optimized out".

I have reproduced with a simple Rust program compiled to either wasm32-wasip1 or wasm32-wasip2:

fn main() {
    let x = 42;
    let y = "foo";
    println!("Hello, world!");
}

With this debug profile in Cargo.toml:

[profile.dev]
opt-level = 0
debug = true

Running with Wasmtime 42.0.0 (or 41.0.4) and LLDB, then listing variables results in the message no location, value may have been optimized out for all variables:

lldb -- wasmtime run -D debug-info -O opt-level=0 target/wasm32-wasip1/debug/dwarf-debugging-repro.wasm
(lldb) target create "wasmtime"
Current executable set to '/Users/radu/.wasmtime/bin/wasmtime' (arm64).
(lldb) settings set -- target.run-args  "run" "-D" "debug-info" "-O" "opt-level=0" "target/wasm32-wasip1/debug/dwarf-debugging-repro.wasm"
(lldb) settings set plugin.jit-loader.gdb.enable on
(lldb) b src/main.rs:5
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 94942 launched: '/Users/radu/.wasmtime/bin/wasmtime' (arm64)
3 locations added to breakpoint 1
Process 94942 stopped
* thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000107e1c3b0 JIT(0x8a6028000)`dwarf_debugging_repro::main::h15ad2e2a588792ef at main.rs:5:5
   2        let x: i32 = 42;
   3        let y: i64 = 100;
   4        let msg: &str = "hello";
-> 5        println!("x={} y={} msg={}", x, y, msg);
   6    }
Target 0: (wasmtime) stopped.
(lldb) frame variable
(WasmtimeVMContext *) __vmctx = 0x00000008a7258ca0
(int) x = <no location, value may have been optimized out>

(long) y = <no location, value may have been optimized out>

(&str) msg = <no location, value may have been optimized out>

(lldb) 

Disclaimer: I have a patch to Wasmtime generated with Claude (plus description) that allows me to retrieve the variables when debugging with lldb:
(I do not claim to fully understand how it works, which is why this is not a PR; feel free to use or ignore the patch I linked):

lldb -- wasmtime-with-the-patch run -D debug-info -O opt-level=0 target/wasm32-wasip2/debug/dwarf-debugging-repro.wasm
(lldb) settings set -- target.run-args  "run" "-D" "debug-info" "-O" "opt-level=0" "target/wasm32-wasip2/debug/dwarf-debugging-repro.wasm"
(lldb) settings set plugin.jit-loader.gdb.enable on
(lldb) b src/main.rs:5
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 96860 launched: '/Users/radu/projects/github.com/spinframework/wasmtime/target/release/wasmtime' (arm64)
3 locations added to breakpoint 1
Process 96860 stopped
* thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001089d86bc JIT(0xaba000000)`dwarf_debugging_repro::main::hb42100e0c21c7fa3 at main.rs:5:5
   2        let x: i32 = 42;
   3        let y: i64 = 100;
   4        let msg: &str = "hello";
-> 5        println!("x={} y={} msg={}", x, y, msg);
   6    }
Target 0: (wasmtime) stopped.
(lldb) frame variable
(WasmtimeVMContext *) __vmctx = 0x0000000abb0c40a0
(int) x = 42
(long) y = 100
(&str) msg = {
  data_ptr = (__ptr = 1048576)
  length = 5
}

Being able to support breakpoint debugging for WASI HTTP components and variable inspection support would be incredibly valuable for the Spin project. Let me know if there is anything I can help with further.

Environment:

$ lldb --version
lldb-1703.0.234.3
Apple Swift version 6.2.1 (swiftlang-6.2.1.4.8 clang-1700.4.4.1)

$ cargo --version                   
cargo 1.93.1 (083ac5135 2025-12-15)

Thanks!

[cfallin]

Thanks for filing the issue! I am actually working on "guest debugging", which is a fully integrated host-level debugger inside Wasmtime that solves this issue in a complete/perfect-fidelity way. It is intended to replace the "native" debugging workflow where you attach LLDB to the host Wasmtime process, which we've known is flaky for some time.

You have good timing here, because I am actually giving a talk about this tomorrow at the second day of the BA Plumber's Summit; feel free to watch for more info. All of the core Wasmtime bits for my work are already in-tree, but the debugger component is not. Free free to read the RFCs (1, 2, 3) for more info. I will demo a working LLDB attached to Wasmtime via a native gdbstub server tomorrow.

Because this is the path forward, I don't think we are going to add a lot of new ad-hoc DWARF fixups. Interestingly, your Claude-produced patch more or less re-invented (borrowed?) the instrumentation approach that guest-debugging also takes, putting Wasm locals in explicit stack slots (but worse: e.g. no support for operand stack, no awareness of inlining, ...). Interesting experiment nonetheless.

I'll go ahead and close this issue but please feel free to ask any questions about the upcoming approach if you'd like.

[alexcrichton]

@cfallin my impression is that we don't want to jettison the DWARF support we have, so while the priority for fixing this might be lower than other debugging-related issues, this seems useful for me to keep open. We have a tranch of issues with the DWARF support we have but also a trickle of fixes coming in over time.

Would you be opposed to me reopening this to track this? If we decide to remove DWARF support I think it's reasonable to close, but otherwise I think it's good to track.

[cfallin]

@alexcrichton we have a bunch of issues like this indeed; if we want to track ongoing issues with DWARF I think we should standardize on one of them (e.g. #3439 to pick a random one) rather than keeping all of them open as they're all essentially the same issue.

I was interpreting the issue more broadly: trying to debug an HTTP component, following the "attach LLDB to Wasmtime process" procedure, and my contention is that for this use-case one really wants to use guest-debugging.

I'm also slightly concerned that the proposed patch here adds essentially another debugging instrumentation pass, in parallel to the existing one. If we want to put more effort into DWARF for host-attached debugging in the future we should probably generate DWARF using our existing instrumentation IMHO.

[alexcrichton]

I was under the impression that each DWARF issue more-or-less is a different cause. For example #9716 is a very similar issue, which is fixed, yet this and #3439 remains. I would personally expect us to keep these issues open and perhaps tag them as DWARF issues to catalogue them.

How certain are you though this is the exact same issue as #3439? I agree there's no need to have duplicate issues, but if the underlying cause is different I think it's useful to have different examples as necessary.

Also I'm not specifically advocating for the attached patch here. The presence of that doesn't invalidate this issue itself, and while that may be somewhat helpful for understanding the underlying issue here I don't think that should guide whether this issue is closed/not.

[cfallin]

You're right, I don't know whether it's the same issue or not. I suppose I lump all of these into "incomplete DWARF fidelity" as one bucket.

There's a deeper question of what we do about incomplete DWARF -- a true fix would be something like the patch linked here, but that creates a whole parallel instrumentation mechanism alongside guest-debugging. In essence we need to either choose "some values will always be missing because we have an optimizing compiler" or "we emit instrumentation so we always have all values", and the latter... already exists.

In that sense I guess I am advocating not continuing to make spot-fixes to the host DWARF infrastructure, because it's a losing battle and goes against the fundamental tradeoff we've already made: by default, we optimize code (and don't insert instrumentation). We have an answer for perfect fidelity, and we've decided not to take on more complexity in the host/native debuginfo handling and associated compiler infra.

Happy to talk about this in the next Wasmtime meeting as well to see what everyone thinks...

@radu-matei can you clarify whether your use-case required attaching LLDB to the native process, versus only debugging the guest code? If the latter, does the guest-debugging as demoed (upstreamed soon hopefully!) meet your needs?

[alexcrichton]

Happy to talk about this in the next Wasmtime meeting as well to see what everyone thinks...

Good idea!

---

I'm going to reopen this in the meantime since it's, at least to me, not necessarily a duplicate of #3439, but this is also pending the outcome of discussion at the next meeting to see how much we want to preserve/push/keep the existing DWARF support.

[radu-matei]

Thanks for the conversation, appreciate it!

My goal is to allow users to debug the programs they are writing, not the Wasmtime embedding itself, and I was following the guide from https://github.com/bytecodealliance/wasmtime/blob/main/docs/examples-debugging-native-debugger.md on how to achieve that today.

Since in this case we don't need to debug hosts, the guest debugging proposal (and awesome demo!) is what we need.

What I don't understand is the level of effort (and time) required to switch to this vs. the existing implementation that already supports setting and stopping on breakpoints during debugging sessions.

Thanks!

[cfallin]

Thanks @radu-matei -- it sounds like guest-debugging is actually better for your use-case then since it avoids confusing the user by stepping through native runtime code.

What I don't understand is the level of effort (and time) required to switch to this vs. the existing implementation that already supports setting and stopping on breakpoints during debugging sessions.

It should be more or less as easy as the current workflow once the last bits (debug-component host, and the gdbstub adapter) are landed. It's not quite "lldb -- wasmtime run ...", it'll be more like "wasmtime run -D ... port=1234" then "lldb" + "connect :1234" in another terminal (as you saw in my demo), but perhaps we could ship a wrapper CLI binary that does all this to give a single-command experience again.