catamorphism opened issue #11337:
Test Case
TODO: upload Wasm file here
Steps to Reproduce
The .wasm file was created with:
clang --target=wasm32-wasip2 --sysroot=$HOME/wasi-libc/sysroot -o function-pointer.wasm function-pointer.c -g -O0and
wasi-libcwas built from source.
function-pointer.cis as follows:struct myfile { int data; void (*f)(); } myfile; void f() {} int foo(struct myfile* f1) { f1->f(); // If the above line is commented out and the next line is uncommented, // it works as expected // f() if (f1->data == 42) return 0; return 1; } int main() { struct myfile f1; f1.f = &f; f1.data = 42; return foo(&f1); }Steps:
lldb -- wasmtime run -D debug-info -O opt-level=0 --wasm component-model --dir .::/ function-pointer.wasm (lldb) b foo (lldb) run (lldb) p f1 (WebAssemblyPtrWrapper<myfile>) (__ptr = 199872) (lldb) n (lldb) p f1 error: Couldn't materialize: couldn't get the value of variable f1: variable not available error: errored out in DoExecute, couldn't PrepareToExecuteJITExpressionExpected Results
I would expect to be able to view
f1in the debugger at any point during the execution offoo().Actual Results
"Couldn't materialize" error as above.
Versions and Environment
Wasmtime version or commit: 35.0.0
Operating system: Linux (Ubuntu 24.04)
Architecture: x86_64
catamorphism added the bug label to Issue #11337.
catamorphism edited issue #11337:
Test Case
TODO: upload Wasm file here
Steps to Reproduce
The .wasm file was created with:
clang --target=wasm32-wasip2 --sysroot=$HOME/wasi-libc/sysroot -o function-pointer.wasm function-pointer.c -g -O0and
wasi-libcwas built from source.
function-pointer.cis as follows:struct myfile { int data; void (*f)(); } myfile; void f() {} int foo(struct myfile* f1) { f1->f(); // If the above line is commented out and the next line is uncommented, // it works as expected // f() if (f1->data == 42) return 0; return 1; } int main() { struct myfile f1; f1.f = &f; f1.data = 42; return foo(&f1); }Steps:
lldb -- wasmtime run -D debug-info -O opt-level=0 --wasm component-model --dir .::/ function-pointer.wasm (lldb) b foo (lldb) run (lldb) p f1 (WebAssemblyPtrWrapper<myfile>) (__ptr = 199872) (lldb) n (lldb) p f1 error: Couldn't materialize: couldn't get the value of variable f1: variable not available error: errored out in DoExecute, couldn't PrepareToExecuteJITExpressionExpected Results
I would expect to be able to view
f1in the debugger at any point during the execution offoo().Actual Results
"Couldn't materialize" error as above.
Versions and Environment
Wasmtime version or commit: 35.0.0
lldb version: 18.1.3
Operating system: Linux (Ubuntu 24.04)
Architecture: x86_64
catamorphism edited issue #11337:
Test Case
Steps to Reproduce
The .wasm file was created with:
clang --target=wasm32-wasip2 --sysroot=$HOME/wasi-libc/sysroot -o function-pointer.wasm function-pointer.c -g -O0and
wasi-libcwas built from source.
function-pointer.cis as follows:struct myfile { int data; void (*f)(); } myfile; void f() {} int foo(struct myfile* f1) { f1->f(); // If the above line is commented out and the next line is uncommented, // it works as expected // f() if (f1->data == 42) return 0; return 1; } int main() { struct myfile f1; f1.f = &f; f1.data = 42; return foo(&f1); }Steps:
lldb -- wasmtime run -D debug-info -O opt-level=0 --wasm component-model --dir .::/ function-pointer.wasm (lldb) b foo (lldb) run (lldb) p f1 (WebAssemblyPtrWrapper<myfile>) (__ptr = 199872) (lldb) n (lldb) p f1 error: Couldn't materialize: couldn't get the value of variable f1: variable not available error: errored out in DoExecute, couldn't PrepareToExecuteJITExpressionExpected Results
I would expect to be able to view
f1in the debugger at any point during the execution offoo().Actual Results
"Couldn't materialize" error as above.
Versions and Environment
Wasmtime version or commit: 35.0.0
lldb version: 18.1.3
Operating system: Linux (Ubuntu 24.04)
Architecture: x86_64
cfallin commented on issue #11337:
Unfortunately I don't have an easy answer/fix, but I'll note that historically our native-debugger support has been quite best-effort, and is more or less unmaintained at the moment. The DWARF translation has had known bugs, and we know that various aspects of our lowering can cause values to become unavailable. All of that to say: I'm not surprised that you are finding holes, and I wouldn't recommend relying on debugging by attaching a native debugger to wasmtime at the moment.
We do have a debugging RFC that captures a lot of thinking about our debugging plans from a year ago; and assuming plans don't change, I should be able to start work on pieces of this later in the year.
fitzgen added the wasmtime:debugging label to Issue #11337.
fitzgen added the cranelift:area:debug label to Issue #11337.
Last updated: Dec 06 2025 at 07:03 UTC