gdb and binutils branch master updated. b7ea362b023feba8d75d5831948bc0d8496b4069

[palves at sourceware dot org]

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  b7ea362b023feba8d75d5831948bc0d8496b4069 (commit)
      from  143e9f4a65664332159aa6eb2f3c4c55cc9f7138 (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=b7ea362b023feba8d75d5831948bc0d8496b4069

commit b7ea362b023feba8d75d5831948bc0d8496b4069
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Jan 8 18:55:51 2014 +0000

    [remote/gdbserver] Don't lose signals when reconnecting.
    
    Currently, when GDB connects in all-stop mode, GDBserver always
    responds to the status packet with a GDB_SIGNAL_TRAP, even if the
    program is actually stopped for some other signal.
    
     (gdb) tar rem ...
     ...
     (gdb) c
     Program received signal SIGUSR1, User defined signal 1.
     (gdb) disconnect
     (gdb) tar rem ...
     (gdb) c
    
    (Or a GDB crash instead of an explicit disconnect.)
    
    This results in the program losing that signal on that last continue,
    because gdb will tell the target to resume with no signal (to suppress
    the GDB_SIGNAL_TRAP, due to 'handle SISGTRAP nopass'), and that will
    actually suppress the real signal the program had stopped for
    (SIGUSR1).  To fix that, I think we should make GDBserver report the
    real signal the thread had stopped for in response to the status
    packet:
    
     @item ?
     @cindex @samp{?} packet
     Indicate the reason the target halted.  The reply is the same as for
     step and continue.
    
    But, that raises the question -- which thread are we reporting the
    status for?  Due to how the RSP in all-stop works, we can only report
    one status.  The status packet's response is a stop reply packet, so
    it includes the thread identifier, so it's not a problem packet-wise.
    However, GDBserver is currently always reporting the status for first
    thread in the thread list, even though that may well not be the thread
    that got the signal that caused the program to stop.  So the next
    logical step would be to report the status for the
    last_ptid/last_status thread (the last event reported to gdb), if it's
    still around; and if not, fallback to some other thread.
    
    There's an issue on the GDB side with that, though...
    
    GDB currently always adds the thread reported in response to the
    status query as the first thread in its list.  That means that if we
    start with e.g.,
    
     (gdb) info threads
       3 Thread 1003 ...
     * 2 Thread 1002 ...
       1 Thread 1001 ...
    
    And reconnect:
    
     (gdb) disconnect
     (gdb) tar rem ...
    
    We end up with:
    
     (gdb) info threads
       3 Thread 1003 ...
       2 Thread 1001 ...
     * 1 Thread 1002 ...
    
    Not a real big issue, but it's reasonably fixable, by having GDB
    fetch/sync the thread list before fetching the status/'?', and then
    using the status to select the right thread as current on the GDB
    side.  Holes in the thread numbers are squashed before/after
    reconnection (e.g., 2,3,5 becomes 1,2,3), but the order is preserved,
    which I think is both good, and good enough.
    
    However (yes, there's more...), the previous GDB that was connected
    might have had gdbserver running in non-stop mode, or could have left
    gdbserver doing disconnected tracing (which also forces non-stop), and
    if the new gdb/connection is in all-stop mode, we can end up with more
    than one thread with a signal to report back to gdb.  As we can only
    report one thread/status (in the all-stop RSP variant; the non-stop
    variant doesn't have this issue), we get to do what we do at every
    other place we have this situation -- leave events we can't report
    right now as pending, so that the next resume picks them up.
    
    Note all this ammounts to a QoI change, within the existing framework.
    There's really no RSP change here.
    
    The only user visible change (other than that the signal is program is
    stopped at isn't lost / is passed to the program), is in "info
    program", that now can show the signal the program stopped for.  Of
    course, the next resume will respect the pass/nopass setting for the
    signal in question.  It'd be reasonable to have the initial connection
    tell the user the program was stopped with a signal, similar to when
    we load a core to debug, but I'm leaving that out for a future change.
    I think we'll need to either change how handle_inferior_event & co
    handle stop_soon, or maybe bypass them completely (like
    fork-child.c:startup_inferior) for that.
    
    Tested on x86_64 Fedora 17.
    
    gdb/gdbserver/
    2014-01-08  Pedro Alves  <palves@redhat.com>
    
    	* gdbthread.h (struct thread_info) <status_pending_p>: New field.
    	* server.c (visit_actioned_threads, handle_pending_status): New
    	function.
    	(handle_v_cont): Factor out parts to ...
    	(resume): ... this new function.  If in all-stop, and a thread
    	being resumed has a pending status, report it without actually
    	resuming.
    	(myresume): Adjust to use the new 'resume' function.
    	(clear_pending_status_callback, set_pending_status_callback)
    	(find_status_pending_thread_callback): New functions.
    	(handle_status): Handle the case of multiple threads having
    	interesting statuses to report.  Report threads' real last signal
    	instead of always reporting GDB_SIGNAL_TRAP.  Look for a thread
    	with an interesting thread to report the status for, instead of
    	always reporting the status of the first thread.
    
    gdb/
    2014-01-08  Pedro Alves  <palves@redhat.com>
    
    	* remote.c (remote_add_thread): Add threads silently if starting
    	up.
    	(remote_notice_new_inferior): If in all-stop, and starting up,
    	don't call notice_new_inferior.
    	(get_current_thread): New function, factored out from ...
    	(add_current_inferior_and_thread): ... this.  Adjust.
    	(remote_start_remote) <all-stop>: Fetch the thread list.  If we
    	found any thread, then select the remote's current thread as GDB's
    	current thread too.
    
    gdb/testsuite/
    2014-01-08  Pedro Alves  <palves@redhat.com>
    
    	* gdb.threads/reconnect-signal.c: New file.
    	* gdb.threads/reconnect-signal.exp: New file.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                  |   12 ++
 gdb/gdbserver/ChangeLog                        |   18 ++
 gdb/gdbserver/gdbthread.h                      |    3 +
 gdb/gdbserver/server.c                         |  210 +++++++++++++++++++-----
 gdb/remote.c                                   |   86 ++++++++--
 gdb/testsuite/ChangeLog                        |    5 +
 gdb/testsuite/gdb.threads/reconnect-signal.c   |   67 ++++++++
 gdb/testsuite/gdb.threads/reconnect-signal.exp |   84 ++++++++++
 8 files changed, 428 insertions(+), 57 deletions(-)
 create mode 100644 gdb/testsuite/gdb.threads/reconnect-signal.c
 create mode 100644 gdb/testsuite/gdb.threads/reconnect-signal.exp


hooks/post-receive
-- 
gdb and binutils