JDevlieghere wrote:

> Sure, so this is like qemu-user? You want to debug the wasm process being 
> hosted within the runtime not the runtime itself.
>
> Because the internet is 99% "use a web browser" for debug, then 
> https://docs.wasmtime.dev/examples-debugging-native-debugger.html seems to be 
> about debugging the runtime with a small amount of the wasm side, can't tell 
> much from that page.

Yep, it's the typical choice between "user" vs "system" debugging. Both are 
valuable and have their own strengths. I think the approach wasmtime took is a 
good choice for it, but it wouldn't make sense for something like V8 where 
you'd have to debug the whole JavaScript runtime to debug your Wasm code. Hence 
why I think the "user" approach is the most promising, generally speaking.

> 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 don't think that's harsh at all. I think I made almost entirely the same 
point in one of Paolo's original PRs. 
 
> 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.

I was under the impression that we had reached consensus on this in the various 
previous PRs. My read of the situation was that there were some practical 
issues (like the PRs being to big, etc) but no fundamental objections to the 
approach. Admittedly, I should've included that assumption explicitly in this 
PR. 

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

Not really, this is back to the difference between debugging your runtime (i.e. 
WAMR or V8) vs debugging the client. To use an analogy, it's the difference 
between debugging the kernel and looking at its data structures to figure out 
the processes vs using debugserver to debug a userspace program.

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

I wouldn't even call it debugging WASM. You're debugging native code that 
happened to be JITed from 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.

Correct, although since they use V8, if they exposed that debug stub, they'd 
get native debugging with LLDB out of the box.
 
> > 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.

Sounds good, we can list WAMR and V8 and say that we support anyone that 
implements the GDB remote protocol plus the handful of WASM extensions (which 
we'll document). 

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

That seems fair and a good way to flush out issues once we've added support for 
everything we know is missing. 

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

https://github.com/llvm/llvm-project/issues/150449

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

Haha, I appreciate the engagement. Thanks for all the input!

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

Reply via email to