Preserve selected thread in all-stop w/ background execution

In non-stop mode, if you resume the program in the background (with
"continue&", for example), then gdb makes sure to not switch the
current thread behind your back.  That means that you can be sure that
the commands you type apply to the thread you selected, even if some
other thread that was running in the background hits some event just
while you're typing.

In all-stop mode, however, if you resume the program in the
background, gdb let's the current thread switch behind your back.

This is bogus, of course.  All-stop and non-stop background
resumptions should behave the same.

This patch fixes that, and adds a testcase that exposes the bad
behavior in current master.

The fork-running-state.exp changes are necessary because that
preexisting testcase was expecting the old behavior:

Before:

  continue &
  Continuing.
  (gdb)
  [Attaching after process 8199 fork to child process 8203]
  [New inferior 2 (process 8203)]
  info threads
    Id   Target Id                      Frame
    1.1  process 8199 "fork-running-st" (running)
  * 2.1  process 8203 "fork-running-st" (running)
  (gdb)

After:

  continue &
  Continuing.
  (gdb)
  [Attaching after process 24660 fork to child process 24664]
  [New inferior 2 (process 24664)]
  info threads
    Id   Target Id                       Frame
  * 1.1  process 24660 "fork-running-st" (running)
    2.1  process 24664 "fork-running-st" (running)
  (gdb)

Here we see that before this patch GDB switches current inferior to
the new inferior behind the user's back, as a side effect of handling
the fork.

The delete_exited_threads call in inferior_appeared is there to fix an
issue that Baris found in a previous version of this patch.  The
fetch_inferior_event change increases the refcount of the current
thread, and in case the fetched inferior event denotes a thread exit,
the thread will not be deleted right away.  A non-deleted but exited
thread stays in the inferior's thread list.  This, in turn, causes the
"init_thread_list" call in inferior.c to be skipped.  A consequence is
that the global thread ID counter is not restarted if the current
thread exits, and then the inferior is restarted:

 (gdb) start
 Temporary breakpoint 1 at 0x4004d6: file main.c, line 21.
 Starting program: /tmp/main

 Temporary breakpoint 1, main () at main.c:21
 21        foo ();
 (gdb) info threads -gid
   Id   GId  Target Id            Frame
 * 1    1    process 16106 "main" main () at main.c:21
 (gdb) c
 Continuing.
 [Inferior 1 (process 16106) exited normally]
 (gdb) start
 Temporary breakpoint 2 at 0x4004d6: file main.c, line 21.
 Starting program: /tmp/main

 Temporary breakpoint 2, main () at main.c:21
 21        foo ();
 (gdb) info threads -gid
   Id   GId  Target Id            Frame
 * 1    2    process 16138 "main" main () at main.c:21
       ^^^

Notice that GId == 2 above.  It should have been "1" instead.

The new tids-git-reset.exp testcase exercises the problem above.

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

	* gdbthread.h (scoped_restore_current_thread)
	<dont_restore, restore, m_dont_restore>: Declare.
	* thread.c (thread_alive): Add assertion.  Return bool.
	(switch_to_thread_if_alive): New.
	(prune_threads): Switch inferior/thread.
	(print_thread_info_1): Switch thread before calling target methods.
	(scoped_restore_current_thread::restore): New, factored out from
	...
	(scoped_restore_current_thread::~scoped_restore_current_thread):
	... this.
	(scoped_restore_current_thread::scoped_restore_current_thread):
	Add assertion.
	(thread_apply_all_command, thread_select): Use
	switch_to_thread_if_alive.

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

	* gdb.base/fork-running-state.exp (do_test): Adjust expected
	output.
	* gdb.threads/async.c: New.
	* gdb.threads/async.exp: New.
	* gdb.multi/tids-gid-reset.c: New.
	* gdb.multi/tids-gid-reset.exp: New.

0 files changed, 0 insertions, 0 deletions