Alex Crichton (Mar 16 2026 at 17:45): Alex Crichton (Mar 16 2026 at 17:45):@Chris Fallin over the weekend I tried your PR (https://github.com/bytecodealliance/wasmtime/pull/12771) to debug https://github.com/WebAssembly/wasi-sdk/issues/616 as I thought it might be an interesting test case. I basically wanted to peek at the interactive state a bit more than the stack trace. Unfortunately I wasn't able to really do much, but I'm not sure if I was holding things wrong necessarily. I figured I'd let know though in case you're interested.
What I ran into was:
breakpoint set address 0x639)continue the debugger exited when the guest trapped meaning that I didn't have a chance to debug anything Alex Crichton (Mar 16 2026 at 17:46):The former I later realized may meant that I needed to specify an address of 0x40000000639 or whatever (I didn't take the address map into account), and the latter might be that we have debug hooks on host-initiated traps but not segfaulting traps? (IIRC those are slightly different paths, but I forget the exact specifics)
Chris Fallin (Mar 16 2026 at 18:46):Interesting experience report, thanks!
0x400...639. Not much we can do about that without an LLDB patch (and then, what would 0x639 mean: which Wasm module, if there are multiple? that's the semantic gap that the address map bridges) Alex Crichton (Mar 16 2026 at 19:39):If I type breakpoint set address 0x639, do you know if LLDB sends 0x639 over to this method? Or does it block it for being out of range or something before sending it over the wire?
Alex Crichton (Mar 16 2026 at 19:39):b/c I figured in that method we could do some cleverness, but if LLDB is the one blocking it we're out of luck yeah
Chris Fallin (Mar 16 2026 at 19:46):I haven't actually checked what goes over the wire, just extrapolating from symptoms + the disassembly view showing "mapped" addresses... I guess we could try to special-case it but that feels wrong in a dangerous way as soon as there is more than one module loaded
Alex Crichton (Mar 16 2026 at 19:54):oh now that's a good point yeah
Alex Crichton (Mar 16 2026 at 19:54):I wish we could return error messages to go back over the wire to the LLDB UI
Alex Crichton (Mar 16 2026 at 19:55):a bland "error 22 setting breakpoint" is very unhelpful
Chris Fallin (Mar 16 2026 at 19:55):yep, it's not great
Alex Crichton (Mar 16 2026 at 19:55):but this is also where once we have docs it'd also probably ameliorate things
Chris Fallin (Mar 16 2026 at 19:55):yep, and on the bright side, relatively few people will be trying to debug bytecode and directly entering PCs; and if they do, "copy the mapped address from the disassembly" is pretty straightforward to document
Alex Crichton (Mar 16 2026 at 19:56):that's what I do all the time with native too, so I think I was trying to be too clever by half by setting the breakpoint ahead of time
Chris Fallin (Mar 16 2026 at 19:56):I'm actually curious if line-number info for WATs works... the dream experience would be to have VSCode load up a WAT, click in the left margin to set a breakpoint, hit run...
Alex Crichton (Mar 16 2026 at 19:57):oh now that can work! I think?
Alex Crichton (Mar 16 2026 at 19:57):wasm-tools parse -g foo.wat -o foo.wasm inserts DWARF in the output
Alex Crichton (Mar 16 2026 at 19:57):just the line table
Alex Crichton (Mar 16 2026 at 19:57):none of that's plumbed into Wasmtime yet but we pretty easily could (and it's already plumbed for wasmtime wast which has line numbers in backtraces by default)
Chris Fallin (Mar 16 2026 at 19:58):oh, the cool thing is that it doesn't have to be plumbed into Wasmtime, I think: LLDB reads out the whole Wasm module directly over the wire, so as long as LLDB understands the line-number table, all should be good
Alex Crichton (Mar 16 2026 at 19:58):indeed!
Chris Fallin (Mar 16 2026 at 19:58):ok well I'll experiment more with this later... 9pm is dinnertime in Barcelona (so I'm told; learned the hard way that 5pm wasn't)
Ralph (Mar 16 2026 at 22:06):if it appears in LLDB, vscode will pick it up automagically
Ralph (Mar 16 2026 at 22:07):I'm not sure, but I think the wasm debugging experience can dump the WAIT to walk through, or maybe I'm imagining it. I'll check with the engineer who did that
Chris Fallin (Mar 17 2026 at 01:39):Alex Crichton said:
- When I let the guest
continuethe debugger exited when the guest trapped meaning that I didn't have a chance to debug anything
this is fixed now in this commit on the PR
(also found another issue and sent you a separable PR re: breakpoints at starts of functions)
I'll take a look at your review comments (thanks!) sometime tomorrow probably before wasm i/o ramps up, or if not, once i'm back on the old (new) continent
guest271314 (Mar 17 2026 at 05:28):I followed the instructions here https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/README.md#using to adapt 2 working WASI Preview 1 files to WASI Preview 2. When I execute the Component Model output file I get this error
Caused by:
no exported instance named `wasi:cli/run@0.2.6`
Reading the output WIT file, there's no mention of run.
Chris Fallin (Mar 19 2026 at 01:13):this is fixed now in this commit on the PR
and now truly fixed by one more commit on top (pulled out as #12802, will rebase out once that lands) -- I was bothered by the way that traps were landing on the inst after the null deref in my little local test and turns out it was a silly lack of metadata
Last updated: Mar 23 2026 at 18:16 UTC