gdb: Handle W and X remote packets without giving a warning
authorAndrew Burgess <andrew.burgess@embecosm.com>
Wed, 11 Mar 2020 12:30:13 +0000 (12:30 +0000)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Thu, 19 Mar 2020 11:16:53 +0000 (11:16 +0000)
commitcada5fc921e39a1945c422eea055c8b326d8d353
tree99e4d731b9a132f96adfad10705760e6ee20e01c
parent6b8c53f2f1c0cf5bee46120d892d4c72571375eb
gdb: Handle W and X remote packets without giving a warning

In this commit:

  commit 24ed6739b699f329c2c45aedee5f8c7d2f54e493
  Date:   Thu Jan 30 14:35:40 2020 +0000

      gdb/remote: Restore support for 'S' stop reply packet

A regression was introduced such that the W and X packets would give a
warning in some cases.  The warning was:

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

This problem would arise when:

  1. The multi-process extensions to the remote protocol were not
  being used, and

  2. The inferior has multiple threads.

In this case when the W (or X) packet arrives the ptid of the
stop_reply is set to null_ptid, then when we arrive in
process_stop_reply GDB spots that we have multiple non-exited theads,
but the stop event didn't specify a thread-id.

The problem with this is that the W (and X) packets are actually
process wide events, they apply to all threads.  So not specifying a
thread-id is not a problem, in fact, the best these packets allow is
for the remote to specify a process-id, not a thread-id.

If we look at how the W (and X) packets deal with a specified
process-id, then what happens is GDB sets to stop_reply ptid to a
value which indicates all threads in the process, this is done by
creating a value `ptid_t (pid)`, which sets the pid field of the
ptid_t, but leaves the tid field as 0, indicating all threads.

So, this commit does the same thing for the case where there is not
process-id specified.  In process_stop_reply we not distinguish
between stop events that apply to all threads, and those that apply to
only one.  If the stop event applies to only one thread then we treat
it as before.  If, however, the stop event applies to all threads,
then we find the first non-exited thread, and use the pid from this
thread to create a `ptid_t (pid)` value.

If the target has multiple inferiors, and receives a process wide
event without specifying a process-id GDB now gives this warning:

  warning: multi-inferior target stopped without sending a process-id, using first non-exited inferior

gdb/ChangeLog:

* remote.c (remote_target::process_stop_reply): Handle events for
all threads differently.

gdb/testsuite/ChangeLog:

* gdb.server/exit-multiple-threads.c: New file.
* gdb.server/exit-multiple-threads.exp: New file.
gdb/ChangeLog
gdb/remote.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.server/exit-multiple-threads.c [new file with mode: 0644]
gdb/testsuite/gdb.server/exit-multiple-threads.exp [new file with mode: 0644]