DavidSpickett wrote: > Hence why I think the "user" approach is the most promising, generally > speaking.
Agreed. If I want to debug qemu-user I treat it like any other program, if I want the simulated process I connect to the internal stub. Some will want integrated solutions but that can come later). > 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. You weren't wrong, the point of an RFC would have been more to be a place to bring up all the weird details one might need to know to think about how this work will work e.g. the address spaces and the endian and only having a PC and so on. But we're having that discussion now so it's fine. There's no massive issues with this PR itself so it's not causing confusion. > I'd be happy to keep chatting about this if you're interested in exploring > that path further, now or in the future. I also don't want to necessarily > push you towards the GDB remote protocol. For languages like C++, Rust, > Swift, or really anything targeting LLVM/supported by LLDB, I strongly > believe that going with the GDB remote protocol is the best and easiest way > to support debugging, but I also totally acknowledge that the trade-offs may > be different for Wasmtime. That said, they also don't necessarily need to be > mutually exclusive. Also the GDB remote protocol is very loosely a standard and has many problems, so in a general sense I do want to hear what projects who aren't required to use it want to do. I am interested to read the WASM debug proposals and see what fresh perspectives there are. > The part of the debugger that handles symbol and debug information is big, > requires access to lots of large files, allocates lots of memory, etc. So you > really want to be able to run lldb itself on the biggest system you have to > hand, not the system on which you run the program you are inspecting, which > might be a resource constrained device. I wonder if it's intentional on WAMR's part to choose the gdb-remote protocol for this reason. I can understand why the "hosted" runtimes would want to take on more code for bigger benefits though. > I'm not sure if it's a bug or if it's because the #77949 patch has been split > into incremental patches. @JDevlieghere do you have a WIP tree they can use that has more changes? 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
