Multiple Ada task-specific breakpoints at the same address.

With the test changed as in the patch, against current mainline, we get:

 (gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
 break break_me task 1
 Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
 (gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
 break break_me task 3
 Note: breakpoint 2 also set at pc 0x4030b0.
 Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
 (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
 continue
 Continuing.
 [Switching to Thread 0x7ffff7dc7700 (LWP 27133)]

 Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
 27	      null;
 (gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
 info tasks
    ID       TID P-ID Pri State                  Name
     1    63b010       48 Waiting on RV with 3   main_task
     2    63bd80    1  48 Accept or Select Term  task_list(1)
 *   3    63f510    1  48 Accepting RV with 1    task_list(2)
     4    642ca0    1  48 Accept or Select Term  task_list(3)
 (gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint

The breakpoint that caused a stop is breakpoint 3, but GDB end up
reporting (and running breakpoint commands of) "Breakpoint 2" instead.

The issue is that the bpstat_check_breakpoint_conditions logic of
"wrong thread" is missing the "wrong task" check.  This is usually
harmless, because the thread hop code in infrun.c code that handles
wrong-task-hitting-breakpoint does check for task-specific breakpoints
(within breakpoint_thread_match):

      /* Check if a regular breakpoint has been hit before checking
         for a potential single step breakpoint.  Otherwise, GDB will
         not see this breakpoint hit when stepping onto breakpoints.  */
      if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
	{
	  if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
	    thread_hop_needed = 1;
	}

IOW, usually, when one only has a task specific breakpoint at a given
address, things work correctly.  Put another task-specific or
non-task-specific breakpoint there, and things break.

A patch that eliminates the special thread hop code in infrun.c is
what exposed this, as after that GDB solely relies on
bpstat_check_breakpoint_conditions to know whether the right or wrong
task hit a breakpoint.  IOW, given the latent bug, Ada task-specific
breakpoints become non-task-specific, and that is caught by the
testsuite, as:

 break break_me task 3
 Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
 (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
 continue
 Continuing.
 [Switching to Thread 0x7ffff7fcb700 (LWP 17122)]

 Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
 27	      null;
 (gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
 info tasks
    ID       TID P-ID Pri State                  Name
     1    63b010       48 Waiting on RV with 2   main_task
 *   2    63bd80    1  48 Accepting RV with 1    task_list(1)
     3    63f510    1  48 Accept or Select Term  task_list(2)
     4    642ca0    1  48 Accept or Select Term  task_list(3)
 (gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint

It was after seeing this that I thought of how to expose the bug with
current mainline.

Tested on x86_64 Fedora 17.

gdb/
2014-02-26  Pedro Alves  <palves@redhat.com>

	* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
	task-specific breakpoints.

gdb/testsuite/
2014-02-26  Pedro Alves  <palves@redhat.com>

	* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
	that won't ever trigger.  Make sure that GDB reports the correct
	breakpoint that caused the stop.

4 files changed, 41 insertions, 8 deletions

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 16f4619..3a02a49 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2014-02-26  Pedro Alves  <palves@redhat.com>
+
+	* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
+	task-specific breakpoints.
+
 2014-02-25  Pedro Alves  <palves@redhat.com>
 
 	* ia64-linux-nat.c (ia64_linux_xfer_partial): Reimplement
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index ef81443..45c3417 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -5159,7 +5159,6 @@ bpstat_check_watchpoint (bpstat bs)
 static void
 bpstat_check_breakpoint_conditions (bpstat bs, ptid_t ptid)
 {
-  int thread_id = pid_to_thread_id (ptid);
   const struct bp_location *bl;
   struct breakpoint *b;
   int value_is_zero = 0;
@@ -5184,9 +5183,12 @@ bpstat_check_breakpoint_conditions (bpstat bs, ptid_t ptid)
       return;
     }
 
-  /* If this is a thread-specific breakpoint, don't waste cpu evaluating the
-     condition if this isn't the specified thread.  */
-  if (b->thread != -1 && b->thread != thread_id)
+  /* If this is a thread/task-specific breakpoint, don't waste cpu
+     evaluating the condition if this isn't the specified
+     thread/task.  */
+  if ((b->thread != -1 && b->thread != pid_to_thread_id (ptid))
+      || (b->task != 0 && b->task != ada_get_task_number (ptid)))
+
     {
       bs->stop = 0;
       return;
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index d54ed98..09cc8a3 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2014-02-26  Pedro Alves  <palves@redhat.com>
+
+	* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
+	that won't ever trigger.  Make sure that GDB reports the correct
+	breakpoint that caused the stop.
+
 2014-02-25  Jan Kratochvil  <jan.kratochvil@redhat.com>
 
 	PR gdb/16626
diff --git a/gdb/testsuite/gdb.ada/tasks.exp b/gdb/testsuite/gdb.ada/tasks.exp
index 710deb0..088be6d 100644
--- a/gdb/testsuite/gdb.ada/tasks.exp
+++ b/gdb/testsuite/gdb.ada/tasks.exp
@@ -37,15 +37,35 @@ gdb_test "info tasks" \
                "\r\n"] \
          "info tasks before inserting breakpoint"
 
-# Now, insert a breakpoint that should stop only if task 3 stops.
-gdb_test "break break_me task 3" "Breakpoint .* at .*"
+# Insert a breakpoint that should stop only if task 1 stops.  Since
+# task 1 never calls break_me, this shouldn't actually ever trigger.
+# The fact that this breakpoint is created _before_ the next one
+# matters.  GDB used to have a bug where it would report the first
+# breakpoint in the list that matched the triggered-breakpoint's
+# address, no matter which task it was specific to.
+gdb_test "break break_me task 1" "Breakpoint .* at .*"
+
+# Now, insert a breakpoint that should stop only if task 3 stops, and
+# extract its number.
+set bp_number -1
+set test "break break_me task 3"
+gdb_test_multiple $test $test {
+    -re "Breakpoint (.*) at .*$gdb_prompt $" {
+	set bp_number $expect_out(1,string)
+	pass $test
+    }
+}
+
+if {$bp_number < 0} {
+    return
+}
 
 # Continue to that breakpoint.  Task 2 should hit it first, and GDB
 # is expected to ignore that hit and resume the execution.  Only then
 # task 3 will hit our breakpoint, and GDB is expected to stop at that
-# point.
+# point.  Also make sure that GDB reports the correct breakpoint number.
 gdb_test "continue" \
-         ".*Breakpoint.*, foo.break_me \\(\\).*" \
+         ".*Breakpoint $bp_number, foo.break_me \\(\\).*" \
          "continue to breakpoint"
 
 # Check that it is indeed task 3 that hit the breakpoint by checking