]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/gdbserver/ChangeLog
GDBserver: ctrl-c after leader has exited
authorPedro Alves <palves@redhat.com>
Wed, 12 Nov 2014 11:17:39 +0000 (11:17 +0000)
committerPedro Alves <palves@redhat.com>
Wed, 12 Nov 2014 11:30:49 +0000 (11:30 +0000)
commit78708b7c8ccc2138880217de9bd60eceff683f10
tree14879775cc59226c4afd3361647616dd69fed1f1
parent6218dc4bdb198bc4982516ba0b8a6714c9123a8f
GDBserver: ctrl-c after leader has exited

The target->request_interrupt callback implements the handling for
ctrl-c.  User types ctrl-c in GDB, GDB sends a \003 to the remote
target, and the remote targets stops the program with a SIGINT, just
like if the user typed ctrl-c in GDBserver's terminal.

The trouble is that using kill_lwp(signal_pid, SIGINT) sends the
SIGINT directly to the program's main thread.  If that thread has
exited already, then that kill won't do anything.

Instead, send the SIGINT to the process group, just like GDB
does (see inf-ptrace.c:inf_ptrace_stop).

gdb.threads/leader-exit.exp is extended to cover the scenario.  It
fails against GDBserver before the patch.

Tested on x86_64 Fedora 20, native and GDBserver.

gdb/gdbserver/
2014-11-12  Pedro Alves  <palves@redhat.com>

* linux-low.c (linux_request_interrupt): Always send a SIGINT to
the process group instead of to a specific LWP.

gdb/testsuite/
2014-11-12  Pedro Alves  <palves@redhat.com>

* gdb.threads/leader-exit.exp: Test sending ctrl-c works after the
leader has exited.
gdb/gdbserver/ChangeLog
gdb/gdbserver/linux-low.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.threads/leader-exit.c
gdb/testsuite/gdb.threads/leader-exit.exp