This is the mail archive of the
gdb-cvs@sourceware.org
mailing list for the GDB project.
gdb and binutils branch master updated. 40e91bc71f7993f2064cec4ffd007f2c814a1b29
- From: palves at sourceware dot org
- To: gdb-cvs at sourceware dot org
- Date: 12 Nov 2014 11:35:58 -0000
- Subject: gdb and binutils branch master updated. 40e91bc71f7993f2064cec4ffd007f2c814a1b29
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".
The branch, master has been updated
via 40e91bc71f7993f2064cec4ffd007f2c814a1b29 (commit)
via c2c118cfe13264f5638f9e3924c7fd05a293ad40 (commit)
via 78708b7c8ccc2138880217de9bd60eceff683f10 (commit)
from 6218dc4bdb198bc4982516ba0b8a6714c9123a8f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=40e91bc71f7993f2064cec4ffd007f2c814a1b29
commit 40e91bc71f7993f2064cec4ffd007f2c814a1b29
Author: Pedro Alves <palves@redhat.com>
Date: Wed Nov 12 11:17:40 2014 +0000
GDBserver: clean up 'cont_thread' handling
As no place in the backends check cont_thread anymore, we can stop
setting and clearing it in places that resume the target and wait for
events. Instead simply clear it whenever a new GDB connects.
gdb/gdbserver/
2014-11-12 Pedro Alves <palves@redhat.com>
* server.c (cont_thread): Update comment.
(start_inferior, attach_inferior): No longer clear cont_thread.
(handle_v_cont): No longer set cont_thread.
(captured_main): Clear cont_thread each time a GDB connects.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c2c118cfe13264f5638f9e3924c7fd05a293ad40
commit c2c118cfe13264f5638f9e3924c7fd05a293ad40
Author: Pedro Alves <palves@redhat.com>
Date: Wed Nov 12 11:17:39 2014 +0000
GDBserver: don't resume all threads if the Hc thread disapears
There's code in linux_wait_1 that resumes all threads if the Hc thread
disappears. It's the wrong thing to do, as GDB has told GDBserver to
resume only one thread, because e.g., the user has scheduler-locking
enabled, or because GDB was stepping the program over a breakpoint.
Resuming all threads behind GDB's back can't be good in either case.
The right thing to do is to detect that that the (only) resumed thread
is gone, and let GDB know about it. The Linux backend is already
doing that nowadays, since:
commit fa96cb382c12b099675c5cc238aaa7352a3fd3d7
Author: Pedro Alves <palves@redhat.com>
AuthorDate: Thu Feb 27 14:30:08 2014 +0000
Teach GDBserver's Linux backend about no unwaited-for children (TARGET_WAITKIND_NO_RESUMED).
The backend detects that all resumed threads have disappeared, and
returns TARGET_WAITKIND_NO_RESUMED to the core of GDBserver, which
then reports an error to GDB.
There's no need to frob the passed in ptid to wait for the continue
thread either -- linux_wait_for_event only returns events for resumed
threads.
The badness (of resuming threads) can actually be observed in the
testsuite, if we force-disable vCont support in GDBserver -- before
the patch, gdb.threads/no-unwaited-for-left.exp hangs if we disable
vCont:
(gdb) continue
Continuing.
FAIL: gdb.threads/no-unwaited-for-left.exp: continue to breakpoint: break-here (timeout)
... more cascading timeouts ....
After the patch, gdb.threads/no-unwaited-for-left.exp behaves the same
with or without vCont support:
(gdb) continue
Continuing.
[New Thread 32226]
[Switching to Thread 32226]
Breakpoint 2, thread_a (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/no-unwaited-for-left.c:28
28 return 0; /* break-here */
(gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue to breakpoint: break-here
...
continue
Continuing.
warning: Remote failure reply: E.No unwaited-for children left.
[Thread 32222] #1 stopped.
(gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
Overall, this is also good for getting rid of a RSP detail from the backend.
gdb/gdbserver/
2014-11-12 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_wait_1): Don't force a wait for the Hc
thread, and don't resume all threads if the Hc thread has exited.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=78708b7c8ccc2138880217de9bd60eceff683f10
commit 78708b7c8ccc2138880217de9bd60eceff683f10
Author: Pedro Alves <palves@redhat.com>
Date: Wed Nov 12 11:17:39 2014 +0000
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.
-----------------------------------------------------------------------
Summary of changes:
gdb/gdbserver/ChangeLog | 17 ++++++++++++
gdb/gdbserver/linux-low.c | 41 ++--------------------------
gdb/gdbserver/server.c | 26 +-----------------
gdb/testsuite/ChangeLog | 5 +++
gdb/testsuite/gdb.threads/leader-exit.c | 3 +-
gdb/testsuite/gdb.threads/leader-exit.exp | 20 ++++++++++++++
6 files changed, 49 insertions(+), 63 deletions(-)
hooks/post-receive
--
gdb and binutils