JDevlieghere wrote: > How does this relate to / overlap with existing PRs #77949 and #78977? They > are unlikely to get merged by the authors, so I assume you'll make your own > equivalent.
I had totally forgotten about those PRs . Yes, they're iterations of the same patch by @paolosevMSFT (which also I based this patch on). The biggest difference is that I'm breaking it down in smaller pieces to make reviewing them easier. > > qWasmCallStack > > This is a bit of a break from the usual reading unwind info, and I wonder > what other stuff is different in this ecosystem. I've been told that the runtime can have a different stack (separate from the native stack) for the Wasm code and also that the format of call frames may not match native stack frame ABI. > Can we get an RFC with an overview of that? Like are these runtimes generally > implementing GDB stubs, is the debug model super different, that sort of > thing. I'm not sure I'm well versed enough in the world of WASM to create an RFC, but I did do a survey of debugging the different runtimes. - **Wasmtime** is a WebAssembly runtime developed by the Bytecode Alliance. It's a standalone runtime that can execute WebAssembly modules outside of web browsers. Wasmtime uses Cranelift (a code generator) to compile Wasm to native machine code. Debugging works by debugging wasmtime itself, which performs JIT compilation of the WebAssembly bytecode to native code. It also supports translating the generated DWARF debug info, so that native debuggers can work with it to debug the JIT-compiled code. - **Chrome** has a DevTools Plugin for debugging C/C++ WebAssembly applications (using DWARF debug information). It uses LLDB to parse DWARF, but otherwise relies on Chrome’s integrated debugging support for Wasm. - **WebAssembly Micro Runtime** (WAMR) is a lightweight standalone WebAssembly runtime. When built with debugging support, it includes a [GDB remote stub](https://github.com/bytecodealliance/wasm-micro-runtime/tree/main/core/iwasm/libraries/debug-engine) which a [patched](https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/build-scripts/lldb_wasm.patch) LLDB can talk to. I'm not aware of any other runtimes besides WAMR that support debugging through GDB remote. Of all the approaches, I think it's the most "desirable" going forward. The fact that there is a ByteCode Alliance runtime that supports it makes it even more compelling. > At least testing can be done anywhere the runtime can run, that's a cool > feature. Yes, long term it would be cool if we can build inferiors and decide where to run them (e.g. QEMU, WAMR, etc). In the short term, we can get pretty good test coverage with the GDB remote test cases. To put things more pragmatically, LLDB has partial support for Wasm debugging using gdb-remote. There's an "official" runtime that implements a gdb stub with the necessary extensions. My hope is that going forward, support in LLDB would encourage other runtimes to adopt this as well. https://github.com/llvm/llvm-project/pull/150143 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
