alexcrichton wrote: > I'm bringing @alexcrichton into the loop, he's involved in the Bytecode > Alliance and LLVM, maybe he'll be able to help us on these topics.
👋 FWIW I'm very much an outsider here so I don't fully understand all the dynamics in play per se, but what I can speak more to is plans on the Wasmtime side of things. For Wasmtime we have an [approved RFC](https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-debugging.md) about the methodology and priorities for implementing debugging. This plan primarily goes through the [Debug Adapter Protocol](https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-debugging.md#debug-adapter-protocol) and intentionally [does not natively implement GDB/LLDB integration](https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-debugging.md#gdb-or-lldb) mostly to handle wasm programs that are an interpreter for their own lanuage (e.g. Python-compiled-to-wasm). We do not currently have anyone slated to implement this work as it hasn't been a priority for existing maintainers yet and we haven't had other volunteers. My assumption though would be that if LLDB had a native wasm plugin support then Wasmtime would implement a [debug adapter component](https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-debugging.md#debug-adapter-components) to bridge what Wasmtime would implement natively and what LLDB supported. I'm not personally aware of other runtimes that want to mirror what WAMR is doing here. The current plan for Wasmtime won't include mirroring the support natively, but that's not to say Wasmtime's plan is set in stone and not possible to change either. 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
