I'm trying to remember to kick the tires on wasmtime -g more often now that we have it baked in. I'm working on something in wasi-libc and my code is currently buggy so I wanted to explore a test case with lldb. The source code is here and poll-connect.wasm is the binary I'm working with.
Reproducing this is in one window:
$ ../wasmtime/target/release/wasmtime -g1234 -W component-model-async -Sp3,inherit-network /home/alex/code/wasi-libc/build/p3/test/poll-connect.wasm
Debugger: Debugger listening on 127.0.0.1:1234
Debugger: In LLDB, attach with: process connect --plugin wasm connect://127.0.0.1:1234
and in another window:
$ $WASI_SDK_PATH/bin/lldb
(lldb) process connect --plugin wasm connect://127.0.0.1:1234
Process 1 stopped
* thread #1, stop reason = signal SIGTRAP
frame #0: 0x00000000
error: memory read failed for 0x0
(lldb) b poll_impl
Breakpoint 1: where = wasm-0`poll_impl + 51 at poll.c:334:31, address = 0x4000000000002c61
(lldb) c
Process 1 resuming
Process 1 stopped
* thread #1, stop reason = breakpoint 1.1
frame #0: 0x4000000000002c61 wasm-0`poll_impl(fds=0x0000ff90, nfds=2, timeout=100) at poll.c:334:31
331 // revisited for wasip3. Maybe make this a dynamically allocated array?
332 size_t max_pollables = (2 * nfds) + 1;
333 state_t states[max_pollables];
-> 334
335 poll_state_t state;
336 state.set = wasip3_waitable_set_new();
337 state.states = states;
(lldb) n
Process 1 stopped
* thread #1, stop reason = signal SIGSEGV
frame #0: 0x400000000000cd72 wasm-0`wasip3_waitable_set_drop(set=5) at wasip3.c:1232:1
1229
1230 void wasip3_waitable_set_drop(wasip3_waitable_set_t set) {
1231 __waitable_set_drop(set);
-> 1232 }
1233
1234 __attribute__((__import_module__("$root"), __import_name__("[waitable-set-wait]")))
1235 extern uint32_t __waitable_set_wait(uint32_t, uint32_t*);
Specifically I'm trying to step through the poll_impl function and inspect local variables. The n command however continues all the way to the end which is a trap that's showing up. The trap is expected (that's the bug), but the lack of stepping is what this bug is about.
This may very well be a bug in LLDB itself, but I figured I'd at least start here as our own support may be a bit more nascent than LLDB's.
I'm trying to remember to kick the tires on
wasmtime -gmore often now that we have it baked in. I'm working on something in wasi-libc and my code is currently buggy so I wanted to explore a test case withlldb. The source code is here and poll-connect.wasm is the binary I'm working with.Reproducing this is in one window:
and in another window:
Specifically I'm trying to step through the
poll_implfunction and inspect local variables. Thencommand however continues all the way to the end which is a trap that's showing up. The trap is expected (that's the bug), but the lack of stepping is what this bug is about.This may very well be a bug in LLDB itself, but I figured I'd at least start here as our own support may be a bit more nascent than LLDB's.