[Lldb-commits] [lldb] [lldb] Add WebAssembly Process Plugin (PR #150143)

[David Spickett via lldb-commits]

DavidSpickett wrote:

This is an overly harsh way of phrasing it, but hopefully it gives you an idea of why I'm asking for an overview of this effort:
* We already have at least one barely tested architecture, I would like to avoid picking up another one.

I think WASM is cool (all WASM userspace when?), I think not having bugs is cool too. I personally trust that you have done the leg work, but I have to verify that at least a bit, as I would with any other random contributor.

I also know that WASM is a hot topic so for this work to get the best reception, a statement of intent might draw interest, and set expectations appropriately.

But ok, as an RFC would be unlikely to generate actual objections, I'll say what I think here.

> The biggest difference is that I'm breaking it down in smaller pieces to make reviewing them easier.

Great, they were a bit much.

> 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.

So they have designed their server specifically to allow debugging both? I wonder how they manage that. A multi-architecture target would be interesting (ala ARM64EC on Windows) but I presume it's different targets. Can lldb handle that? It doesn't have to but it sounds pretty cool if it can.

> Wasmtime
> It also supports translating the generated DWARF debug info, so that native debuggers can work with it to debug the JIT-compiled code.

So for this, you aren't stepping WASM instructions, you're debugging it like any other native JIT. The input to that JIT just happens to be WASM.

> Chrome has a [DevTools Plugin for debugging C/C++ WebAssembly](https://developer.chrome.com/docs/devtools/wasm) applications (using DWARF debug information). It uses LLDB to parse DWARF, but otherwise relies on Chrome’s integrated debugging support for Wasm.

Yeah, 99% of the internet says "just use chrome" to debug. So we're not going to plug in to this part of it then.

> 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.

We will need to state which runtime we intend to support and one from the people writing the standard is the best choice I agree.

I suppose it running on small devices that cannot host a browser is why they went that way, do the debugger UI stuff elsewhere.

> 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.

We can get a surprising amount of coverage that way, that is true.

What we can't do is answer `is random lldb command supposed to work with wasm`? That's what a test suite run would provide.

Ultimately I would prefer regular test suite runs using this WASM runtime, but I would settle for a manual run that gives us a snapshot of the state of WASM support.

Finally, could you open a meta-issue for WASM support? Like we have for [RISC-V](https://github.com/llvm/llvm-project/issues/55383) and [LoongArch](https://github.com/llvm/llvm-project/issues/112693).

Ofc these issues get outdated pretty fast but at least it's something we can put on the website and folks can ask their "should X work" questions.

...now I've ranted enough about process let me review some actual code :)

https://github.com/llvm/llvm-project/pull/150143