[PATCHv3 2/2] gdb/remote: Restore support for 'S' stop reply packet

[Tom Tromey]

Andrew> There was a regression in GDB's support for older aspects of the
Andrew> remote protocol.  Specifically, when a target sends the 'S' stop reply
Andrew> packet (which doesn't include a thread-id) then GDB has to figure out
Andrew> which thread actually stopped.

With this patch, I started seeing this warning when running the AdaCore
internal test suite using qemu.

I investigated a little and the warning comes from this packet:

    Packet received: W00
    warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread

It seems to me that the warning must not be correct in this case, though
I am not 100% sure, so I thought I would ask.

My reason is that this is a whole-process exit (so reporting a thread
doesn't make sense); and that in this run, qemu is not reporting that it
is multi-process-capable (so reporting a PID doesn't make sense).

So, I wonder if process_stop_reply should be modified like (beware,
untested patch):

diff --git a/gdb/remote.c b/gdb/remote.c
index 9b73faf9a34..810df658c54 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -7666,7 +7666,7 @@ remote_target::process_stop_reply (struct stop_reply *stop_reply,
 
   /* If no thread/process was reported by the stub then use the first
      non-exited thread in the current target.  */
-  if (ptid == null_ptid)
+  if (ptid == null_ptid && stop_reply->stop_reason != TARGET_WAITKIND_EXITED)
     {
       for (thread_info *thr : all_non_exited_threads (this))
 	{


Perhaps this also applies to some of the other TARGET_WAITKIND_ values
as well?  TARGET_WAITKIND_SIGNALLED seems similar.

thanks,
Tom