Workaround remote targets that report an empty list to qfThreadInfo
authorPedro Alves <palves@redhat.com>
Tue, 28 Oct 2014 11:35:10 +0000 (11:35 +0000)
committerPedro Alves <palves@redhat.com>
Tue, 28 Oct 2014 11:35:10 +0000 (11:35 +0000)
commit7d1a114c44db3d7055afe48868f939ba95a64b7b
tree330d325befc9aa5e371d7ee390023b4e1f94d4d2
parent708d7d0d11f0f2d776171979aa3479e8e12a38a0
Workaround remote targets that report an empty list to qfThreadInfo

In https://sourceware.org/ml/gdb-patches/2014-10/msg00652.html, Sandra
shows a target that was broken by the recent update_thread_list
optimization:

 (gdb) target remote qa8-centos32-cs:10514
 ...
 (gdb) continue
 Continuing.
 Cannot execute this command without a live selected thread.
 (gdb)

The error means that the current thread is in "exited" state when the
continue command is processed.  The root of the problem was found
here:

 > Sending packet: $Hg0#df...Packet received:
 ...
 > Sending packet: $?#3f...Packet received: S00
 > Sending packet: $qfThreadInfo#bb...Packet received: l
 > Sending packet: $Hc-1#09...Packet received:
 > Sending packet: $qC#b4...Packet received: unset

This target doesn't really support threads (no thread indication in
stop reply packets; no support for qC), but then supports
qfThreadInfo, and returns an empty thread list to GDB.

See https://sourceware.org/ml/gdb-patches/2014-10/msg00665.html for
why the target does that.

As remote_update_thread_list deletes threads from GDB's list that are
not found in the thread list that the target reports, the result is
that GDB deletes the "fake" main thread that GDB added itself.  (As
that thread is currently selected, it is marked "exited" instead of
being deleted straight away.)

This commit avoids deleting the main thread in this scenario.

gdb/
2014-10-27  Pedro Alves  <palves@redhat.com>

* remote.c (remote_thread_alive): New, factored out from ...
(remote_thread_alive): ... this.
(remote_update_thread_list): Bail out before deleting threads if
the target returned an empty list, and, the current thread has a
magic/fake ptid.
gdb/ChangeLog
gdb/remote.c