Toolchain/binutils-gdb
1
0
Fork 0
forked from Imagelibrary/binutils-gdb
Code Pull Requests Activity

Multiple Ada task-specific breakpoints at the same address.

Browse Source 
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.
This commit is contained in:
Pedro Alves
2014-02-26 14:22:33 +00:00
parent e3e3703534
commit 12ab52e977
4 changed files with 41 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
gdb/ChangeLog
View File

@@ -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

10
gdb/breakpoint.c
View File

@@ -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;

6
gdb/testsuite/ChangeLog
View File

@@ -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

28
gdb/testsuite/gdb.ada/tasks.exp
View File

@@ -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