You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reproduction for this problem is to run the WasmDebugging.csrpoj -c Debug test under wasmtime+LLDB:
> (lldb) b Main
> r
> type lookup WasmDebugging_Program
The output will be:
struct WasmDebugging_Program {
static int Main();
}
This is NOT expected, since we have a number of other static methods hanging off of this type. And indeed, if we try to step into them, it will work, but things that rely on .debug_info DIEs more directly, like expression evaluation, will not work. I suspect this problem is also why we often see "debugging information not available" "red" frames in the Chrome debugger.
The root cause is that the way we can duplicate type definitions across bitcode files is not supported by the system. In this case in particular, Main happened to have been compiled into HelloWasm.X.bc, while most other methods - into some other module. This can be observed directly via wasm-tools unbundle WasmDebugging.wasm > $null && llvm-dwarfdump -F unbundled-module0.wasm | sls 'DW_AT_name [DW_FORM_strp] ("WasmDebugging_Program")' -s.
The end result is that LLDB caches the lookup results from the HelloWasm.X compile unit, where Main was recorded, and doesn't realize there are other parts present.
The fix here should be relatively straightforward.
Edit: further investigation with C++ classes revealed that a similar pattern is not handled by the wasmtime DWARF translator either, so we may have two bugs at hand.
The text was updated successfully, but these errors were encountered:
The reproduction for this problem is to run the
WasmDebugging.csrpoj -c Debug
test under wasmtime+LLDB:The output will be:
This is NOT expected, since we have a number of other static methods hanging off of this type. And indeed, if we try to step into them, it will work, but things that rely on
.debug_info
DIEs more directly, like expression evaluation, will not work. I suspect this problem is also why we often see "debugging information not available" "red" frames in the Chrome debugger.The root cause is that the way we can duplicate type definitions across bitcode files is not supported by the system. In this case in particular,
Main
happened to have been compiled intoHelloWasm.X.bc
, while most other methods - into some other module. This can be observed directly viawasm-tools unbundle WasmDebugging.wasm > $null && llvm-dwarfdump -F unbundled-module0.wasm | sls 'DW_AT_name [DW_FORM_strp] ("WasmDebugging_Program")' -s
.The end result is that LLDB caches the lookup results from the
HelloWasm.X
compile unit, whereMain
was recorded, and doesn't realize there are other parts present.The fix here should be relatively straightforward.
Edit: further investigation with C++ classes revealed that a similar pattern is not handled by the wasmtime DWARF translator either, so we may have two bugs at hand.
The text was updated successfully, but these errors were encountered: