]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Cancel execution command on thread exit, when stepping, nexting, etc. users/palves/step-over-thread-exit-v3.1
authorPedro Alves <pedro@palves.net>
Tue, 21 Jun 2022 17:05:19 +0000 (18:05 +0100)
committerPedro Alves <pedro@palves.net>
Fri, 10 Mar 2023 19:14:20 +0000 (19:14 +0000)
commita2321047a01729ae5f4c4f1159048227126c9649
treef23d0bd35b70254b7252277846121f50e86301bc
parentfb3a9c907fb16fad52c52d46a18f6a4d2344d500
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
gdb/infrun.c
gdb/testsuite/gdb.threads/step-over-thread-exit.exp