From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2469 invoked by alias); 26 Feb 2014 14:27:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 2458 invoked by uid 89); 26 Feb 2014 14:27:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 26 Feb 2014 14:27:32 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1QERO1H017533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Feb 2014 09:27:25 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1QERJ80009262; Wed, 26 Feb 2014 09:27:21 -0500 Message-ID: <530DF9C7.3090506@redhat.com> Date: Wed, 26 Feb 2014 14:27:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: [PATCH 3.5/6] Multiple Ada task-specific breakpoints at the same address. References: <1393360363-5603-1-git-send-email-palves@redhat.com> <530DEDCD.9080207@redhat.com> <20140226141901.GD4348@adacore.com> In-Reply-To: <20140226141901.GD4348@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00782.txt.bz2 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 * breakpoint.c (bpstat_check_breakpoint_conditions): Handle task-specific breakpoints. gdb/testsuite/ 2014-02-26 Pedro Alves * 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 + + * breakpoint.c (bpstat_check_breakpoint_conditions): Handle + task-specific breakpoints. + 2014-02-25 Pedro Alves * 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 + + * 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 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