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().

0 files changed, 0 insertions, 0 deletions