Fix reconnecting to a gdbserver already debugging multiple processes, II
authorPedro Alves <palves@redhat.com>
Fri, 10 Jan 2020 20:05:54 +0000 (20:05 +0000)
committerPedro Alves <palves@redhat.com>
Fri, 10 Jan 2020 20:05:54 +0000 (20:05 +0000)
commit75c6c844d9df37761e0e834df057b89e41816e55
tree37e07a6eee038a2f9645b5e1a349b08544ea9a4e
parent78f2c40a12179d26d3065c09f054b7e751b2732f
Fix reconnecting to a gdbserver already debugging multiple processes, II

Another bug exposed by gdb.server/extended-remote-restart.exp in the
multi-target work is that remote_target::start_remote can leave
inferior_ptid and current_inferior() out of sync:

 (top-gdb) p current_inferior_->pid
 $1 = 29541
 (top-gdb) p inferior_ptid
 $2 = {m_pid = 29540, m_lwp = 29540, m_tid = 0}

This is caused by writing to inferior_ptid directly instead of using
switch_to_thread.  Also, "inferior_list->thread_list->ptid" assumes
that we want the first thread of the first inferior, but that inferior
may not have threads, or with multi-target, that target may be
connected to some other target.

gdb/ChangeLog:
2020-01-10  Pedro Alves  <palves@redhat.com>

* remote.c (remote_target::start_remote): Don't set inferior_ptid
directly.  Instead find the first thread in the thread list and
use switch_to_thread.
gdb/ChangeLog
gdb/remote.c