gdb, btrace: switch threads in remote_btrace_maybe_reopen()

In remote_btrace_maybe_reopen() we iterate over threads and use
set_general_thread() to set the thread from which to transfer the btrace
configuration.

This sets the remote general thread but does not affect inferior_ptid.  On
the xfer request later on, remote_target::xfer_partial() again sets the
remote general thread to inferior_ptid, overwriting what
remote_btrace_maybe_reopen() had done.

In one case, this led to inferior_ptid being null_ptid when we tried to
enable tracing on a newly created thread inside a newly created process
during attach.

This, in turn, led to find_inferior_pid() asserting when we iterated over
threads in record_btrace_is_replaying(), which was called from
record_btrace_target::xfer_partial() when reading the btrace configuration
of the new thread to check whether it was already being recorded.

The bug was exposed by

    0618ae41497 gdb: optimize all_matching_threads_iterator

and found by

    FAIL: gdb.btrace/enable-new-thread.exp: ... (GDB internal error)

Use switch_to_thread() in remote_btrace_maybe_reopen().

diff --git a/gdb/remote.c b/gdb/remote.c
index bb41a18daf9ee6792789d27b5fead138cb4a8e77..f19a2f7c1f9e47fc696ed1243afb0b65896eee0b 100644 (file)
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -14136,7 +14136,7 @@ remote_target::remote_btrace_maybe_reopen ()
 
   for (thread_info *tp : all_non_exited_threads (this))
     {
-      set_general_thread (tp->ptid);
+      switch_to_thread (tp);
 
       memset (&rs->btrace_config, 0x00, sizeof (struct btrace_config));
       btrace_read_config (&rs->btrace_config);