This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3.5/6] Multiple Ada task-specific breakpoints at the same address.
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 26 Feb 2014 14:27:19 +0000
- Subject: Re: [PATCH 3.5/6] Multiple Ada task-specific breakpoints at the same address.
- Authentication-results: sourceware.org; auth=none
- References: <1393360363-5603-1-git-send-email-palves at redhat dot com> <530DEDCD dot 9080207 at redhat dot com> <20140226141901 dot GD4348 at adacore dot com>
On 02/26/2014 02:19 PM, Joel Brobecker wrote:
> It all looks good to me. Just a few nits I happen to notice:
>
>> +# 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 this this breakpoint is created _before_ the next one
> ^^^^^^^^^
> that this?
Indeed.
>
>> +# matter. GDB used to have a bug where it would report the first
> ^^^^^^
> matters
Righto.
Pushed with those changes. Thanks!
----------
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.
---
gdb/ChangeLog | 5 +++++
gdb/breakpoint.c | 10 ++++++----
gdb/testsuite/ChangeLog | 6 ++++++
gdb/testsuite/gdb.ada/tasks.exp | 28 ++++++++++++++++++++++++----
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
--
1.7.11.7