tree f23d0bd35b70254b7252277846121f50e86301bc
parent fb3a9c907fb16fad52c52d46a18f6a4d2344d500
author Pedro Alves <pedro@palves.net> 1655831119 +0100
committer Pedro Alves <pedro@palves.net> 1678475660 +0000

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)

Change-Id: I901ab64c91d10830590b2dac217b5264635a2b95