[review] Handle pending stops from the Windows kernel

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

>> +  else if (desired_stop_thread_id != -1 && desired_stop_thread_id != thread_id)
>> +    {
>> +      /* Pending stop.  See the comment by the definition of
>> +	 "pending_stops" for details on why this is needed.  */
>> +      DEBUG_EVENTS (("get_windows_debug_event - "
>> +		     "unexpected stop in 0x%x (expecting 0x%x)\n",
>> +		     thread_id, desired_stop_thread_id));
>> +
>> +      pending_stops.push_back ({thread_id, *ourstatus, current_event});

Pedro> I think you should unwind the PC here, not only when returning the pending
Pedro> event to GDB core.  Consider the case of two threads hitting a breakpoint
Pedro> at the same time.  When that happens, and do you "info threads", you want to
Pedro> see the PC of all threads pointing at a valid instruction.  If you don't
Pedro> unwind the PC of pending breakpoints, then the threads with pending breakpoints
Pedro> will have their PC offset by one.

I think I tried this, but I can try again.

>> +	      if (software_breakpoint_inserted_here_p (regcache->aspace (), pc))

Pedro> Why is software_breakpoint_inserted_here_p needed?  

Offsetting the PC did not work without this.
I tried to document my findings here:

https://sourceware.org/ml/gdb-patches/2019-10/msg00338.html

IIRC what happened is that gdb would sometimes resume the inferior with
wrong PC, causing it to crash.  However, I don't really recall, since it
was a long time ago now.  I guess I'll re-do the experiments.

Tom