Tim Chevalier (Jul 31 2025 at 22:01): Tim Chevalier (Jul 31 2025 at 22:01):Hi,
For background, I'm working on porting wasi-libc to use native wasip2 rather than relying on the preview1 component adapter. As an auxiliary task, I'm trying to improve test coverage so I know what the baseline behavior is with the component adapter. I'm trying to debug a test in lldb and am finding that there doesn't seem to be any debug info for functions defined in the component adapter. I added a new test that calls posix_fdadvise() and I want to set a breakpoint in the fd_advise() function defined in the component adapter. The breakpoint works, but the JITted code is displayed rather than the Rust source code:
Process 1934747 stopped
* thread #1, name = 'wasmtime', stop reason = breakpoint 1.5
frame #0: 0x00007ffff60950a0 JIT(0x7ffff5d77010)`fd_advise(var0=<unavailable>, var1=<unavailable>, var2=<unavailable>, var3=<unavailable>)
JIT(0x7ffff5d77010)`fd_advise:
-> 0x7ffff60950a0 <+0>: pushq %rbp
0x7ffff60950a1 <+1>: movq %rsp, %rbp
0x7ffff60950a4 <+4>: movq 0x8(%rdi), %r10
0x7ffff60950a8 <+8>: movq 0x10(%r10), %r10
I already recompiled the wasi-preview1-component-adapter crate for debugging and changed wasi-libc's test Makefile to use my debug version rather than the downloaded one from github, and am using a debug build of wasmtime. I also added "-g -O0" to CFLAGS. Otherwise, the test Makefile is unmodified, so the test is compiled like:
clang-19 --target=wasm32-wasip2 --sysroot=../sysroot -Ibuild/download/libc-test/src/common -g -O0 -resource-dir ../build/wasm32-wasip2/resource-dir -Wl,--skip-wit-component build/wasm32-wasip2/misc/fadvise.wasm.o build/wasm32-wasip2/common/path.wasm.o build/wasm32-wasip2/common/print.wasm.o build/wasm32-wasip2/common/rand.wasm.o build/wasm32-wasip2/common/utf8.wasm.o -o build/wasm32-wasip2/misc/fadvise.core.wasm
build/download/wasm-tools-1.224.0-x86_64-linux/wasm-tools component new --adapt /home/tjc/wasmtime/target/wasm32-unknown-unknown/debug/wasi_snapshot_preview1.wasm build/wasm32-wasip2/misc/fadvise.core.wasm -o build/wasm32-wasip2/misc/fadvise.component.wasm
and then my lldb command is:
lldb -- /home/tjc/wasmtime/target/debug/wasmtime run -D debug-info -O opt-level=0 --wasm component-model --dir fs::/ /home/tjc/wasi-libc/test/build/wasm32-wasip2/misc/fadvise.component.wasm
I would expect there to be debuginfo for fd_advise since I compiled both wasmtime and the wasi-preview1-component-adapter crate with debugging enabled. (For wasi-preview1-component-adapter, I used:
cargo build -p wasi-preview1-component-adapter --target wasm32-unknown-unknown --features command --no-default-features
Any suggestions?
Thanks,
Tim
Alex Crichton (Jul 31 2025 at 22:48):Ah yes unfortunately this is expected. Way-back-when I figured "surely no one will want to gdb the adapter right?" and so everything was built assuming that it won't be necessary.
Specifically what happens is that as part of the componentization process the adapter is "GC'd" where unnecessary exports are pruned. That shuffles the code section (and deletes imports for example) which destroys all DWARF debug info. Nothing rewrites the DWARF info after the GC pass and either wit-component drops custom sections in the adapter entirely or doesn't bother to update them, resulting in either missing or broken DWARF.
In short, unfortunately this isn't possible, the adapter can't be debugged with lldb
Alex Crichton (Jul 31 2025 at 22:49):In the abstract I've found debugging the adapter to be extremely difficult historically as well. It's such a limited "language" in that you can't even use println or standard utilities like that
Alex Crichton (Jul 31 2025 at 22:50):One wild idea would be to avoid GC'ing the adapter entirely and instead just preserve everything. Such a flag of behavior in wit-component though (which is used as part of wasm-component-ld and wasm-tools component new) isn't yet implemented
Tim Chevalier (Jul 31 2025 at 23:03):Thanks for the explanation! I'll try to figure out what kind of workaround I need.
Last updated: Dec 06 2025 at 06:05 UTC