JDevlieghere wrote: > I see two new ways that LLDB and Wasmtime could interact in the future (on > top of the existing way by attaching LLDB to a native Wasmtime process and > debugging Wasm (and native code) via the JIT code registration system APIs): > > 1. LLDB's TUI frontend could be a client, connected to Wasmtime as a server, > and they speak the debug adapter protocol to each other.
I'm personally skeptical of this part. LLDB's command line driver is very small and doesn't do much. You absolutely could turn that into a DAP client, but you wouldn't get much in return. Most of the "TUI" parts of LLDB are tightly coupled with the core of the library. For folks to retain the same "look and feel", you would have to reimplement all the commands in terms of DAP operations. Doable of course, but likely a lot of work for very little return. > 2. LLDB could be compiled to Wasm (ideally as a library, but there are ways a > Wasm binary with a `main` could be embedded) and used to implement a "debug > adapter component". Debug adapter components are [Wasm > components](https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md) > that layer source-level debugging on top of Wasm-machine-level debugging. > They export a source-level debugging interface and import a wasm-level > debugging interface (which is implemented by Wasmtime itself). When the > debugger frontend sends a set-breakpoint request over the debug adapter > protocol, for example, Wasmtime will translate that protocol request into an > invocation of the associated function in the debug adapter component's > exported source-level interface. Then the debug adapter component would (in > this case) invoke its LLDB library to determine where to set breakpoints in > Wasm, and then finally invoke its imported Wasm-level debugging interface to > actually have Wasmtime set those breakpoints in its JIT code. How about instead of compiling LLDB to Wasm, we compile a small binary to Wasm and run that in process, handling the callbacks. If that hypothetical server implemented the GDB remote protocol, you basically have how we do debugging on Linux/Windows (`lldb-server`) and Darwin (`debugserver`). > Both of the above could even happen at the same time. > > We could also potentially implement a GDB protocol shim as a debug adapter > component. Seems possible but I haven't fully thought it through. I'd be happy to keep chatting about this if you're interested in exploring that path further, now or in the future. I also don't want to necessarily push you towards the GDB remote protocol. For languages like C++, Rust, Swift, or really anything targeting LLVM/supported by LLDB, I strongly believe that going with the GDB remote protocol is the best and easiest way to support debugging, but I also totally acknowledge that the trade-offs may be different for Wasmtime. That said, they also don't necessarily need to be mutually exclusive. 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
