]> 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
authorPedro Alves <pedro@palves.net>
Tue, 21 Jun 2022 17:05:19 +0000 (18:05 +0100)
committerPedro Alves <pedro@palves.net>
Mon, 18 Jul 2022 16:34:41 +0000 (17:34 +0100)
commit1a41079f044ea4911e8fa71549c96379ec97e1a4
treee268b6176261b3bd0d41f5471de7881cb8b07034
parent9ba356a18fe45bddf21ebecf21914ea56df7f9e4
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