clayborg added a comment. 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 - modify the GDB remote protocol to handle a new "qSupported" variant that asks if variables and stacks are supported via the API. Most GDB servers will answer with not supported. See https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qSupported - modify ProcessGDBRemote and ThreadGDBRemote to override these APIs and answer "true" to handling variables and stack if the server supports this. - Modify the unwind code to ask the lldb_private::Thread if it provides a backtrace. If true, then skip the normal unwind and use the new APIs on lldb_private::Thread - Remove the ProcessWasm code and UnwindWasm code. 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
