aboutsummaryrefslogtreecommitdiff
path: root/gdb
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2020-01-10 20:05:54 +0000
committerPedro Alves <palves@redhat.com>2020-01-10 20:05:54 +0000
commit75c6c844d9df37761e0e834df057b89e41816e55 (patch)
tree37e07a6eee038a2f9645b5e1a349b08544ea9a4e /gdb
parent78f2c40a12179d26d3065c09f054b7e751b2732f (diff)
downloadfsf-binutils-gdb-75c6c844d9df37761e0e834df057b89e41816e55.zip
fsf-binutils-gdb-75c6c844d9df37761e0e834df057b89e41816e55.tar.gz
fsf-binutils-gdb-75c6c844d9df37761e0e834df057b89e41816e55.tar.bz2
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.
Diffstat (limited to 'gdb')
-rw-r--r--gdb/ChangeLog6
-rw-r--r--gdb/remote.c12
2 files changed, 15 insertions, 3 deletions
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 4163c86..a6fd8b1 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,11 @@
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.
+
+2020-01-10 Pedro Alves <palves@redhat.com>
+
* remote.c (remote_target::remote_add_inferior): Don't bind a
process to the current inferior if the current inferior is already
bound to a process.
diff --git a/gdb/remote.c b/gdb/remote.c
index 751769e..f017f4a 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -4701,8 +4701,8 @@ remote_target::start_remote (int from_tty, int extended_p)
says should be current. If we're reconnecting to a
multi-threaded program, this will ideally be the thread
that last reported an event before GDB disconnected. */
- inferior_ptid = get_current_thread (wait_status);
- if (inferior_ptid == null_ptid)
+ ptid_t curr_thread = get_current_thread (wait_status);
+ if (curr_thread == null_ptid)
{
/* Odd... The target was able to list threads, but not
tell us which thread was current (no "thread"
@@ -4714,8 +4714,14 @@ remote_target::start_remote (int from_tty, int extended_p)
"warning: couldn't determine remote "
"current thread; picking first in list.\n");
- inferior_ptid = inferior_list->thread_list->ptid;
+ for (thread_info *tp : all_non_exited_threads ())
+ {
+ switch_to_thread (tp);
+ break;
+ }
}
+ else
+ switch_to_thread (find_thread_ptid (curr_thread));
}
/* init_wait_for_inferior should be called before get_offsets in order