https://github.com/felipepiovezan commented:
The problems here seem to come from the fact that Windows doesn't do a separate process for debugging, so maybe not all abstractions have the necessary hooks. Comparing each case against the corresponding implementation of ProcessGDBRemote might yield some interesting results. For example, let's look at `ProcessWindows::DoResume` and the equivalent GDB process. The windows case iterates over real threads and casts the real thread to `TargetWindowsThread`, calling `DoResume` on each; this is _not_ a virtual method, so it doesn't exist in the base thread implementation. The Windows implementation is trying to do its own thing outside the `Thread` hierarchy. In the GDBRemote case, we have `ThreadGDBRemote::WillResume` put its own thread ID into a list (`m_continue_C_tids`) inside `ProcessGDBRemote`, and then `ProcessGDBRemote::DoResume` queries that list. LLDB's machinery is guaranteed to call `Thread::WillResume` at the right time, and `ThreadMemory::WillResume` just forwards this to the real thread. Note that `TargetWindowsThread::WillResume` uses the base class empty implementation. For this example, there are probably two ways forward: 1. Just assume all threads in the real thread list will actually resume and iterate over them like this PR does. 2. Use the `Thread::WillResume -> Process::DoResume` chain like the GDBRemote implementation does. Likewise for another example: GetTriggeredHardwareBreakpointSlotId. This method is not a virtual `RegisterContext` method, though maybe here it is fine to look at the real thread list... My point is, it would be good to do a more thorough comparison with how ProcessGDBRemote handles all the cases you're trying to handle here. https://github.com/llvm/llvm-project/pull/215574 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
