old-cross-binutils/gdb/testsuite/gdb.ada/tasks.exp
Pedro Alves 12ab52e977 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.
2014-02-26 14:22:33 +00:00

85 lines
3.1 KiB
Text

# Copyright 2009-2014 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
load_lib "ada.exp"
standard_ada_testfile foo
if {[gdb_compile_ada "${srcfile}" "${binfile}" executable [list debug ]] != "" } {
return -1
}
clean_restart ${testfile}
set bp_location [gdb_get_line_number "STOP_HERE" ${testdir}/foo.adb]
runto "foo.adb:$bp_location"
# Make sure that all tasks appear in the "info tasks" listing, and
# that the active task is the environment task.
gdb_test "info tasks" \
[join {" +ID +TID P-ID Pri State +Name" \
"\\* +1 .* main_task" \
" +2 .* task_list\\(1\\)" \
" +3 .* task_list\\(2\\)" \
" +4 .* task_list\\(3\\)"} \
"\r\n"] \
"info tasks before inserting breakpoint"
# 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. Also make sure that GDB reports the correct breakpoint number.
gdb_test "continue" \
".*Breakpoint $bp_number, foo.break_me \\(\\).*" \
"continue to breakpoint"
# Check that it is indeed task 3 that hit the breakpoint by checking
# which is the active task.
gdb_test "info tasks" \
[join {" +ID +TID P-ID Pri State +Name" \
" +1 .* main_task" \
" +2 .* task_list\\(1\\)" \
"\\* +3 .* task_list\\(2\\)" \
" +4 .* task_list\\(3\\)"} \
"\r\n"] \
"info tasks after hitting breakpoint"
# Now, resume the execution and make sure that GDB does not stop when
# task 4 hits the breakpoint. Continuing thus results in our program
# running to completion.
gdb_continue_to_end "" continue 1