fitzgen wrote: > This is basically describing the GDB remote protocol.
Clarification: The interfaces described in that RFC and that I am describing below are programmatic/function interfaces (specifically [Wasm component](https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md) interfaces) -- not remote protocols. More on the GDB protocol specifically down below. > When you talk about LLDB as a "client", I assume you mean the "debug adapater > component" rather than the "debug adapter protocol"? 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. 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. 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. --------------- Backing up, here are the main reasons we didn't choose the GDB protocol: * It excludes debugging interpreted-in-Wasm programs, as Alex mentioned. Today, we have many users that write Wasm programs in Python or JS that happen to be implemented via compiling the Python/JS interpreter to Wasm and running the user's program inside the interpreter. Users want to debug their Python/JS program, of course, not the interpreter. With debug adapter components, language runtimes have the flexibility to implement their own debug adapter component specific to themselves, enabling source-level debugging of their interpreted programs. * Wasm as a language has a bunch of things that don't fit neatly into the GDB protocol and its idea of an abstract ISA: * it is a harvard architecture with a managed stack and structured control flow (for example, IIRC, the GDB protocol wants stack walking logic to be done on the client and implemented via inspecting raw stack slots the same as any other memory access on the server, and that is not possible with Wasm's managed stack), * it has multiple different kinds of "registers" (value-stack operands, locals, and globals), * it has managed, unforgable references whose bit patterns cannot be inspected and have different valid operations depending on the kind of reference, * GC structs and arrays as core language primitives, whose raw layout, field offsets, alignment, and bits cannot be inspected, and must be accessed only via `struct.get` and similar, * many different memories (`p` is a pointer, but a pointer into which memory?), * tables that are kind of like memories but for managed references, * and probably more things I am forgetting off the top of my head. Now if you want to only support the exact shape of Wasm module that LLVM emits (or at least emits currently, who knows what new shapes it will emit as it grows new features in the future) where there is exactly one memory and managed references aren't used, etc... and you don't care about debugging interpreted programs, then a bunch of these concerns evaporate and/or can be papered over. And maybe then the GDB protocol is pretty viable. But Wasmtime intends to support debugging the full WebAssembly language, including all of its oddities, as well as all Wasm toolchains regardless of which Wasm features they leverage. 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
