[Lldb-commits] [PATCH] D78801: [LLDB] Add class ProcessWasm for WebAssembly debugging

Mon Apr 27 04:47:20 PDT 2020

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