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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
