From patchwork Tue Apr 7 12:49:36 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 6048 Received: (qmail 130682 invoked by alias); 7 Apr 2015 12:50:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 130619 invoked by uid 89); 7 Apr 2015 12:50:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Apr 2015 12:50:02 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 944E7385900 for ; Tue, 7 Apr 2015 12:50:01 +0000 (UTC) Received: from brno.lan (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t37Cnowt022139 for ; Tue, 7 Apr 2015 08:50:01 -0400 From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH v2 09/23] Make gdb.threads/step-over-trips-on-watchpoint.exp effective on !x86 Date: Tue, 7 Apr 2015 13:49:36 +0100 Message-Id: <1428410990-28560-10-git-send-email-palves@redhat.com> In-Reply-To: <1428410990-28560-1-git-send-email-palves@redhat.com> References: <1428410990-28560-1-git-send-email-palves@redhat.com> This test is currently failing like this on PPC64 and s390x: FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=off: no thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=off: no thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=off: with thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=off: with thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: next gdb.log: (gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=off: no thread-specific bp: step: set scheduler-locking off step wait_threads () at ../../../src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:49 49 return 1; /* in wait_threads */ (gdb) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=off: no thread-specific bp: step: step The problem is that the test assumes that both the "watch_me = 1;" and the "other = 1;" lines compile to a single instruction each, which happens to be true on x86, but no necessarily true everywhere else. The result is that the test doesn't really test what it wants to test. Fix it by looking for the instruction that triggers the watchpoint. The test now fails in a different way on PPC, and only when displaced stepping: FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: continue: continue (the program exited) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: continue: continue (the program exited) And that's actually a GDB bug. That is, the test is now effectively doing its job on PPC64 too. gdb/ChangeLog: 2015-04-07 Pedro Alves * gdb.threads/step-over-trips-on-watchpoint.c (child_function): Remove comment. * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Find both the address of the instruction that triggers the watchpoint and the address of the instruction immediately after, and use those addresses for the test. Fix comment. --- .../gdb.threads/step-over-trips-on-watchpoint.c | 2 +- .../gdb.threads/step-over-trips-on-watchpoint.exp | 44 +++++++++++++++++++--- 2 files changed, 40 insertions(+), 6 deletions(-) diff --git a/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c b/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c index 13404da..6cf97fb 100644 --- a/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c +++ b/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c @@ -36,7 +36,7 @@ child_function (void *arg) counter++; watch_me = 1; /* set breakpoint child here */ - other = 1; /* set thread-specific breakpoint here */ + other = 1; usleep (1); } diff --git a/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp b/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp index 7a0fb79..3ccceae 100644 --- a/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp +++ b/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp @@ -37,6 +37,8 @@ if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \ # triggers the watchpoint. proc do_test { displaced with_bp } { global executable + global gdb_prompt + global hex if ${with_bp} { set prefix "with thread-specific bp" @@ -66,13 +68,44 @@ proc do_test { displaced with_bp } { gdb_breakpoint [gdb_get_line_number "set breakpoint child here"] gdb_test "thread 2" "Switching to .*" gdb_continue_to_breakpoint "run to breakpoint in thread 2" + + set address_triggers_watch "" + set after_address_triggers_watch "" + + # Let the watchpoint trigger once (with the other + # thread locked), in order to find both the address of + # the instruction that triggers the watchpoint and the + # address of the instruction immediately after. + with_test_prefix "find addresses" { + gdb_test "p watch_me = 0" " = 0" "clear watch_me" + gdb_test "watch watch_me" "Hardware watchpoint .*" + + gdb_test "continue" \ + "Hardware watchpoint.*: watch_me.*New value = 1.*" \ + "continue to watchpoint" + + set msg "find addresses" + gdb_test_multiple "disassemble" $msg { + -re " ($hex) \[^\r\n\]*\r\n=> ($hex) .*$gdb_prompt $" { + set address_triggers_watch $expect_out(1,string) + set after_address_triggers_watch $expect_out(2,string) + pass $msg + } + } + + delete_breakpoints + } + + gdb_breakpoint "*$address_triggers_watch" + gdb_continue_to_breakpoint \ + "run to instruction that triggers watch in thread 2" + gdb_test "p counter = 0" " = 0" "unbreak loop in thread 2" gdb_test "p watch_me = 0" " = 0" "clear watch_me" gdb_test "watch watch_me" "Hardware watchpoint .*" if ${with_bp} { - set linenum [gdb_get_line_number "set thread-specific breakpoint here"] - gdb_test "b $linenum thread 1" + gdb_test "b *$after_address_triggers_watch thread 1" } # Switch back to thread 1 and disable scheduler locking. @@ -80,9 +113,10 @@ proc do_test { displaced with_bp } { gdb_test_no_output "set scheduler-locking off" # Thread 2 is still stopped at a breakpoint that needs to be - # stepped over before proceeding thread 1. However, right - # where the step-over lands there's another breakpoint - # installed, which should trap and be reported to the user. + # stepped over before proceeding thread 1. However, the + # instruction that is under the breakpoint triggers a + # watchpoint, which should trap and be reported to the + # user. gdb_test "$command" "Hardware watchpoint.*: watch_me.*New value = 1.*" } }