jimingham 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.
The part of the debugger that handles symbol and debug information is big, requires access to lots of large files, allocates lots of memory, etc. So you really want to be able to run lldb itself on the biggest system you have to hand, not the system on which you run the program you are inspecting, which might be a resource constrained device. That's why the gdb-remote protocol or something like it is so attractive. The part that has to run on the system with the debugee is small and doesn't consume a lot of resources, and the part that has to deal with lots of data can run somewhere. 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
