-
Notifications
You must be signed in to change notification settings - Fork 220
Description
I'm trying to find the root cause for the following issue: using a locally-built LLDB from exactly the commit that is referenced as a submodule in this repo, I am able to start Wasmtime (using bytecodealliance/wasmtime#12771) like
% /opt/wasi-sdk/bin/clang -g -O0 test.c -o test.wasm
% wasmtime run -g 1234 test.wasm
.../llvm-project/build % bin/lldb
(lldb) process connect --plugin wasm connect://0:1234
Process 1 stopped
* thread #1, stop reason = signal SIGTRAP
frame #0: 0x4000000000000184 wasm`_start at crt1-command.c:31:9
(note the crt1-command.c:31:9 source location); whereas with LLDB from wasi-sdk,
% /opt/wasi-sdk/bin/lldb
(lldb) process connect --plugin wasm connect://0:1234
Process 1 stopped
* thread #1, stop reason = signal SIGTRAP
frame #0: 0x4000000000000184
-> 0x4000000000000184: block
0x4000000000000186: block
0x4000000000000188: global.get 1
0x400000000000018e: i32.const 3664
(note no source location). Furthermore, in the former LLDB, b main / c works, whereas in the latter, I get
(lldb) b main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
Looking at a trace of gdbstub commands (-Darg=-v -Dinherit-stderr=true on the Wasmtime side), I see that my locally-built LLDB does a qXfer:read:libraries and learns about the Wasm module (then fetches its bytecode) when it first connects, whereas the wasi-sdk LLDB only reads the bytes around PC and gives a local disassembly.
My local build was configured with cmake -S ../llvm -DLLVM_ENABLE_PROJECTS="clang;lldb" -B . -G Ninja (i.e., no custom options other than enabling the relevant projects). There are quite a few custom flags configured here and I haven't bisected which, if any, cause the issue. I've confirmed that I am on LLVM commit 4434dabb69916856b824f68a64b029c67175e532, which is also what is used in wask-sdk v32.
Any thoughts? I'll see if I can poke at this more tomorrow.