labath added a comment. In D78801#2004248 <https://reviews.llvm.org/D78801#2004248>, @clayborg wrote:
> So a few things here. It doesn't seem like it is necessary to create the > WasmProcessGDBRemote and IWasmProcess. It would be fine to extend the current > ProcessGDBRemote and ThreadGDBRemote classes. The whole reason seems to be > that the variables (globals, locals, etc) are fetched through the GDB server > API and that doesn't happen for other users of the protocol where this > information is fetched via the debug info. Is this correct? You seem to have > debug info and DWARF (since you mentioned a new DWARF expression opcode), so > how do variables actually work? Do you use debug info? What info for > variables do you need to fetch from the API? > > It also seems that you fetch the stack backtrace via the GBB remote protocol > as well. This would be easy to add in to the generic GDB remote protocol. > This could also be built in at the lldb_private::Process/lldb_private::Thread > API level where a process/thread specifies it fetches the variables and/or > stack itself instead of letting the unwind engine do its thing. This can be > really useful for instance if a core or minidump file that is able to store a > backtrace so that when you don't have all the system libraries you can still > get a good backtrace from a core file. So the backtrace part should > definitely be part of the core LLDB logic where it can ask a process or > thread if it provides a backtrace or not and we add new virtual APIs to the > lldb_private::Process/lldb_private::Thread classes to detect and handle this. > The ProcessGDBRemote and ThreadGDBRemote would then implement these functions > and answer "yes" if the GDB server supports fetching these things. > > So if you can elaborate in detail how variables work and how the stack trace > works and exactly what needs to go through the GDB server API, we can work > out how this should happen in LLDB. From what I understand right now I would: > > - modify lldb_private::Process/lldb_private::Thread to add new virtual (not > pure virtual) APIs that answer "false" when asked if the process/thread > provides variables and stacks The above idea is fairly interesting, but I don't see why a new API like that would be necessary to implement it. We already have an abstraction for a producer of stack frames -- the `Unwind` class. Reusing the existing abstraction (as this patch does) seems like simpler/cleaner design then adding a new api, and then having users switch on its value. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78801/new/ https://reviews.llvm.org/D78801 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
