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.

1 files changed, 34 insertions, 59 deletions

diff --git a/gdb/infrun.c b/gdb/infrun.c
index 3c58ff2..33aa674 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -623,7 +623,7 @@ proceed_after_vfork_done (struct thread_info *thread,
 			    target_pid_to_str (thread->ptid));
 
       switch_to_thread (thread->ptid);
-      clear_proceed_status ();
+      clear_proceed_status (0);
       proceed ((CORE_ADDR) -1, GDB_SIGNAL_DEFAULT, 0);
     }
 
@@ -1721,15 +1721,6 @@ maybe_software_singlestep (struct gdbarch *gdbarch, CORE_ADDR pc)
   return hw_step;
 }
 
-/* Return a ptid representing the set of threads that we will proceed,
-   in the perspective of the user/frontend.  We may actually resume
-   fewer threads at first, e.g., if a thread is stopped at a
-   breakpoint that needs stepping-off, but that should not be visible
-   to the user/frontend, and neither should the frontend/user be
-   allowed to proceed any of the threads that happen to be stopped for
-   internal run control handling, if a previous command wanted them
-   resumed.  */
-
 ptid_t
 user_visible_resume_ptid (int step)
 {
@@ -1757,6 +1748,12 @@ user_visible_resume_ptid (int step)
       resume_ptid = inferior_ptid;
     }
 
+  /* We may actually resume fewer threads at first, e.g., if a thread
+     is stopped at a breakpoint that needs stepping-off, but that
+     should not be visible to the user/frontend, and neither should
+     the frontend/user be allowed to proceed any of the threads that
+     happen to be stopped for internal run control handling, if a
+     previous command wanted them resumed.  */
   return resume_ptid;
 }
 
@@ -2032,6 +2029,11 @@ clear_proceed_status_thread (struct thread_info *tp)
 			"infrun: clear_proceed_status_thread (%s)\n",
 			target_pid_to_str (tp->ptid));
 
+  /* If this signal should not be seen by program, give it zero.
+     Used for debugging signals.  */
+  if (!signal_pass_state (tp->suspend.stop_signal))
+    tp->suspend.stop_signal = GDB_SIGNAL_0;
+
   tp->control.trap_expected = 0;
   tp->control.step_range_start = 0;
   tp->control.step_range_end = 0;
@@ -2051,26 +2053,24 @@ clear_proceed_status_thread (struct thread_info *tp)
   bpstat_clear (&tp->control.stop_bpstat);
 }
 
-static int
-clear_proceed_status_callback (struct thread_info *tp, void *data)
-{
-  if (is_exited (tp->ptid))
-    return 0;
-
-  clear_proceed_status_thread (tp);
-  return 0;
-}
-
 void
-clear_proceed_status (void)
+clear_proceed_status (int step)
 {
   if (!non_stop)
     {
-      /* In all-stop mode, delete the per-thread status of all
-	 threads, even if inferior_ptid is null_ptid, there may be
-	 threads on the list.  E.g., we may be launching a new
-	 process, while selecting the executable.  */
-      iterate_over_threads (clear_proceed_status_callback, NULL);
+      struct thread_info *tp;
+      ptid_t resume_ptid;
+
+      resume_ptid = user_visible_resume_ptid (step);
+
+      /* In all-stop mode, delete the per-thread status of all threads
+	 we're about to resume, implicitly and explicitly.  */
+      ALL_NON_EXITED_THREADS (tp)
+        {
+	  if (!ptid_match (tp->ptid, resume_ptid))
+	    continue;
+	  clear_proceed_status_thread (tp);
+	}
     }
 
   if (!ptid_equal (inferior_ptid, null_ptid))
@@ -2252,6 +2252,9 @@ proceed (CORE_ADDR addr, enum gdb_signal siggnal, int step)
       regcache_write_pc (regcache, addr);
     }
 
+  if (siggnal != GDB_SIGNAL_DEFAULT)
+    tp->suspend.stop_signal = siggnal;
+
   /* Record the interpreter that issued the execution command that
      caused this thread to resume.  If the top level interpreter is
      MI/async, and the execution command was a CLI command
@@ -2318,38 +2321,6 @@ proceed (CORE_ADDR addr, enum gdb_signal siggnal, int step)
 
   tp->control.trap_expected = tp->stepping_over_breakpoint;
 
-  if (!non_stop)
-    {
-      /* Pass the last stop signal to the thread we're resuming,
-	 irrespective of whether the current thread is the thread that
-	 got the last event or not.  This was historically GDB's
-	 behaviour before keeping a stop_signal per thread.  */
-
-      struct thread_info *last_thread;
-      ptid_t last_ptid;
-      struct target_waitstatus last_status;
-
-      get_last_target_status (&last_ptid, &last_status);
-      if (!ptid_equal (inferior_ptid, last_ptid)
-	  && !ptid_equal (last_ptid, null_ptid)
-	  && !ptid_equal (last_ptid, minus_one_ptid))
-	{
-	  last_thread = find_thread_ptid (last_ptid);
-	  if (last_thread)
-	    {
-	      tp->suspend.stop_signal = last_thread->suspend.stop_signal;
-	      last_thread->suspend.stop_signal = GDB_SIGNAL_0;
-	    }
-	}
-    }
-
-  if (siggnal != GDB_SIGNAL_DEFAULT)
-    tp->suspend.stop_signal = siggnal;
-  /* If this signal should not be seen by program,
-     give it zero.  Used for debugging signals.  */
-  else if (!signal_program[tp->suspend.stop_signal])
-    tp->suspend.stop_signal = GDB_SIGNAL_0;
-
   annotate_starting ();
 
   /* Make sure that output from GDB appears before output from the
@@ -2443,7 +2414,7 @@ init_wait_for_inferior (void)
 
   breakpoint_init_inferior (inf_starting);
 
-  clear_proceed_status ();
+  clear_proceed_status (0);
 
   target_last_wait_ptid = minus_one_ptid;
 
@@ -5190,6 +5161,10 @@ switch_back_to_stepped_thread (struct execution_control_state *ecs)
 	 what keep_going does as well, if we call it.  */
       ecs->event_thread->control.trap_expected = 0;
 
+      /* Likewise, clear the signal if it should not be passed.  */
+      if (!signal_program[ecs->event_thread->suspend.stop_signal])
+	ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
+
       /* If scheduler locking applies even if not stepping, there's no
 	 need to walk over threads.  Above we've checked whether the
 	 current thread is stepping.  If some other thread not the