Cancel execution command on thread exit, when stepping, nexting, etc.
authorPedro Alves <pedro@palves.net>
Tue, 21 Jun 2022 17:05:19 +0000 (18:05 +0100)
committerPedro Alves <pedro@palves.net>
Mon, 13 Nov 2023 14:16:11 +0000 (14:16 +0000)
commit9488c32734e1933ccd4d8b1a920e70d7e6f7a440
tree45abec67bef69eaeb7cfe794e8bb2577b6b4491d
parentb11df22aa7ddfa74ca37ca7c94fb362779d70e15
Cancel execution command on thread exit, when stepping, nexting, etc.

If your target has no support for TARGET_WAITKIND_NO_RESUMED events
(and no way to support them, such as the yet-unsubmitted AMDGPU
target), and you step over thread exit with scheduler-locking on, this
is what you get:

 (gdb) n
 [Thread ... exited]
 *hang*

Getting back the prompt by typing Ctrl-C may not even work, since no
inferior thread is running to receive the SIGINT.  Even if it works,
it seems unnecessarily harsh.  If you started an execution command for
which there's a clear thread of interest (step, next, until, etc.),
and that thread disappears, then I think it's more user friendly if
GDB just detects the situation and aborts the command, giving back the
prompt.

That is what this commit implements.  It does this by explicitly
requesting the target to report thread exit events whenever the main
resumed thread has a thread_fsm.  Note that unlike stepping over a
breakpoint, we don't need to enable clone events in this case.

With this patch, we get:

 (gdb) n
 [Thread 0x7ffff7d89700 (LWP 3961883) exited]
 Command aborted, thread exited.
 (gdb)

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I901ab64c91d10830590b2dac217b5264635a2b95
gdb/infrun.c
gdb/testsuite/gdb.threads/step-over-thread-exit.exp