This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb and binutils branch master updated. 705096250d59d9aaf3855a350edd2f3946777dd4


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  705096250d59d9aaf3855a350edd2f3946777dd4 (commit)
      from  d8be293957340f1cbe16d65d78d64aebc01df18f (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=705096250d59d9aaf3855a350edd2f3946777dd4

commit 705096250d59d9aaf3855a350edd2f3946777dd4
Author: Pedro Alves <palves@redhat.com>
Date:   Fri Jul 25 16:57:31 2014 +0100

    Always pass signals to the right thread
    
    Currently, GDB can pass a signal to the wrong thread in several
    different but related scenarios.
    
    E.g., if thread 1 stops for signal SIGFOO, the user switches to thread
    2, and then issues "continue", SIGFOO is actually delivered to thread
    2, not thread 1.  This obviously messes up programs that use
    pthread_kill to send signals to specific threads.
    
    This has been a known issue for a long while.  Back in 2008 when I
    made stop_signal be per-thread (2020b7ab), I kept the behavior -- see
    code in 'proceed' being removed -- wanting to come back to it later.
    The time has finally come now.
    
    The patch fixes this -- on resumption, intercepted signals are always
    delivered to the thread that had intercepted them.
    
    Another example: if thread 1 stops for a breakpoint, the user switches
    to thread 2, and then issues "signal SIGFOO", SIGFOO is actually
    delivered to thread 1, not thread 2, because 'proceed' first switches
    to thread 1 to step over its breakpoint...  If the user deletes the
    breakpoint before issuing "signal FOO", then the signal is delivered
    to thread 2 (the current thread).
    
    "signal SIGFOO" can be used for two things: inject a signal in the
    program while the program/thread had stopped for none, bypassing
    "handle nopass"; or changing/suppressing a signal the program had
    stopped for.  These scenarios are really two faces of the same coin,
    and GDB can't really guess what the user is trying to do.  GDB might
    have intercepted signals in more than one thread even (see the new
    signal-command-multiple-signals-pending.exp test).  At least in the
    inject case, it's obviously clear to me that the user means to deliver
    the signal to the currently selected thread, so best is to make the
    command's behavior consistent and easy to explain.
    
    Then, if the user is trying to suppress/change a signal the program
    had stopped for instead of injecting a new signal, but, the user had
    changed threads meanwhile, then she will be surprised that with:
    
      (gdb) continue
      Thread 1 stopped for signal SIGFOO.
      (gdb) thread 2
      (gdb) signal SIGBAR
    
    ... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2
    (with scheduler-locking off, which is the default, because then
    "signal" or any other resumption command resumes all threads).
    
    So the patch makes GDB detect that, and ask for confirmation:
    
      (gdb) thread 1
      [Switching to thread 1 (Thread 10979)]
      (gdb) signal SIGUSR2
      Note:
        Thread 3 previously stopped with signal SIGUSR2, User defined signal 2.
        Thread 2 previously stopped with signal SIGUSR1, User defined signal 1.
      Continuing thread 1 (the current thread) with specified signal will
      still deliver the signals noted above to their respective threads.
      Continue anyway? (y or n)
    
    All these scenarios are covered by the new tests.
    
    Tested on x86_64 Fedora 20, native and gdbserver.
    
    gdb/
    2014-07-25  Pedro Alves  <palves@redhat.com>
    
    	* NEWS: Mention signal passing and "signal" command changes.
    	* gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend
    	comment.
    	* breakpoint.c (until_break_command): Adjust clear_proceed_status
    	call.
    	* infcall.c (run_inferior_call): Adjust clear_proceed_status call.
    	* infcmd.c (proceed_thread_callback, continue_1, step_once)
    	(jump_command): Adjust clear_proceed_status call.
    	(signal_command): Warn if other thread that are resumed have
    	signals that will be delivered.  Adjust clear_proceed_status call.
    	(until_next_command, finish_command)
    	(proceed_after_attach_callback, attach_command_post_wait)
    	(attach_command): Adjust clear_proceed_status call.
    	* infrun.c (proceed_after_vfork_done): Likewise.
    	(proceed_after_attach_callback): Adjust comment.
    	(clear_proceed_status_thread): Clear stop_signal if not in pass
    	state.
    	(clear_proceed_status_callback): Delete.
    	(clear_proceed_status): New 'step' parameter.  Only clear the
    	proceed status of threads the command being prepared is about to
    	resume.
    	(proceed): If passed in an explicit signal, override stop_signal
    	with it.  Don't pass the last stop signal to the thread we're
    	resuming.
    	(init_wait_for_inferior): Adjust clear_proceed_status call.
    	(switch_back_to_stepped_thread): Clear the signal if it should not
    	be passed.
    	* infrun.h (clear_proceed_status): New 'step' parameter.
    	(user_visible_resume_ptid): Add comment.
    	* linux-nat.c (linux_nat_resume_callback): Don't check whether the
    	signal is in pass state.
    	* remote.c (append_pending_thread_resumptions): Likewise.
    	* mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call.
    
    gdb/doc/
    2014-07-25  Pedro Alves  <palves@redhat.com>
    	    Eli Zaretskii  <eliz@gnu.org>
    
    	* gdb.texinfo (Signaling) <signal command>: Explain what happens
    	with multi-threaded programs.
    
    gdb/testsuite/
    2014-07-25  Pedro Alves  <palves@redhat.com>
    
    	* gdb.threads/signal-command-handle-nopass.c: New file.
    	* gdb.threads/signal-command-handle-nopass.exp: New file.
    	* gdb.threads/signal-command-multiple-signals-pending.c: New file.
    	* gdb.threads/signal-command-multiple-signals-pending.exp: New file.
    	* gdb.threads/signal-delivered-right-thread.c: New file.
    	* gdb.threads/signal-delivered-right-thread.exp: New file.

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

Summary of changes:
 gdb/ChangeLog                                      |   36 +++++
 gdb/NEWS                                           |   11 ++
 gdb/breakpoint.c                                   |    2 +-
 gdb/doc/ChangeLog                                  |    6 +
 gdb/doc/gdb.texinfo                                |   11 ++-
 gdb/gdbthread.h                                    |    8 +-
 gdb/infcall.c                                      |    2 +-
 gdb/infcmd.c                                       |   64 +++++++--
 gdb/infrun.c                                       |   93 ++++-------
 gdb/infrun.h                                       |    8 +-
 gdb/linux-nat.c                                    |    3 +-
 gdb/mi/mi-main.c                                   |    2 +-
 gdb/remote.c                                       |    3 +-
 gdb/testsuite/ChangeLog                            |    9 +
 .../gdb.threads/signal-command-handle-nopass.c     |   49 ++++++
 .../gdb.threads/signal-command-handle-nopass.exp   |   78 +++++++++
 .../signal-command-multiple-signals-pending.c      |   98 ++++++++++++
 .../signal-command-multiple-signals-pending.exp    |  166 ++++++++++++++++++++
 .../gdb.threads/signal-delivered-right-thread.c    |   61 +++++++
 .../gdb.threads/signal-delivered-right-thread.exp  |   85 ++++++++++
 20 files changed, 716 insertions(+), 79 deletions(-)
 create mode 100644 gdb/testsuite/gdb.threads/signal-command-handle-nopass.c
 create mode 100644 gdb/testsuite/gdb.threads/signal-command-handle-nopass.exp
 create mode 100644 gdb/testsuite/gdb.threads/signal-command-multiple-signals-pending.c
 create mode 100644 gdb/testsuite/gdb.threads/signal-command-multiple-signals-pending.exp
 create mode 100644 gdb/testsuite/gdb.threads/signal-delivered-right-thread.c
 create mode 100644 gdb/testsuite/gdb.threads/signal-delivered-right-thread.exp


hooks/post-receive
-- 
gdb and binutils


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]