Re: [PATCH v2 26/47] Windows gdb+gdbserver: Make current_event per-thread state

Tom Tromey
2025-05-28T19:31:10Z

>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:

Pedro> With non-stop mode, each thread is controlled independently of the
Pedro> others, and each thread has its own independent reason for its last
Pedro> stop.

Pedro> Thus, any thread-specific state that is currently per-process must be
Pedro> converted to per-thread state.

Makes sense.

Pedro> Since each thread will have its own copy of its last Windows debug
Pedro> event, we no longer need the same information stored in struct
Pedro> pending_stop.

I had to go refresh my memory of what happened here, but I see a comment
in gdb/nat/windows-nat.h:

/* A vector of pending stops. Sometimes, Windows will report a stop
on a thread that has been ostensibly suspended. We believe what
happens here is that two threads hit a breakpoint simultaneously,
and the Windows kernel queues the stop events. However, this can
result in the strange effect of trying to single step thread A --
leaving all other threads suspended -- and then seeing a stop in
thread B. To handle this scenario, we queue all such "pending"
stops here, and then process them once the step has completed. See
PR gdb/22992. */

So I think this makes sense as well.

Thanks for doing this.
Approved-By: Tom Tromey <tom@tromey.com>

Tom