From: Pedro Alves <palves@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH v3 13/17] Fix step-over-{trips-on-watchpoint|lands-on-breakpoint}.exp race
Date: Fri, 17 Apr 2015 10:45:00 -0000 [thread overview]
Message-ID: <1429267521-21047-14-git-send-email-palves@redhat.com> (raw)
In-Reply-To: <1429267521-21047-1-git-send-email-palves@redhat.com>
On a target that is both always in non-stop mode and can do displaced
stepping (such as native x86_64 GNU/Linux, with "maint set
target-non-stop on"), the step-over-trips-on-watchpoint.exp test
sometimes fails like this:
(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: thread 1
set scheduler-locking off
(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: set scheduler-locking off
step
-[Switching to Thread 0x7ffff7fc0700 (LWP 11782)]
-Hardware watchpoint 4: watch_me
-
-Old value = 0
-New value = 1
-child_function (arg=0x0) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:39
-39 other = 1; /* set thread-specific breakpoint here */
-(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step
+wait_threads () at /home/pedro/gdb/mygit/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: no thread-specific bp: step: step
Note "scheduler-locking" was set off. The problem is that on such
targets, the step-over of thread 2 and the "step" of thread 1 can be
set to run simultaneously (since with displaced stepping the
breakpoint isn't ever removed from the target), and sometimes, the
"step" of thread 1 finishes first, so it'd take another resume to see
the watchpoint trigger. Fix this by replacing the wait_threads
function with a one-line infinite loop that doesn't call any function,
so that the "step" of thread 1 never finishes.
gdb/testsuite/ChangeLog:
2015-04-17 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-lands-on-breakpoint.c (wait_threads):
Delete function.
(main): Add alarm. Run an infinite loop instead of calling
wait_threads.
* gdb.threads/step-over-lands-on-breakpoint.exp (do_test): Change
comment.
* gdb.threads/step-over-trips-on-watchpoint.c (wait_threads):
Delete function.
(main): Add alarm. Run an infinite loop instead of calling
wait_threads.
* gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Change
comment.
v3:
- Rebased.
---
.../gdb.threads/step-over-lands-on-breakpoint.c | 17 ++++++++++-------
.../gdb.threads/step-over-lands-on-breakpoint.exp | 6 +++---
.../gdb.threads/step-over-trips-on-watchpoint.c | 17 ++++++++++-------
.../gdb.threads/step-over-trips-on-watchpoint.exp | 9 ++++-----
4 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.c b/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.c
index 0a6ed8f..2480164 100644
--- a/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.c
+++ b/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.c
@@ -41,23 +41,26 @@ child_function (void *arg)
pthread_exit (NULL);
}
-static int
-wait_threads (void)
-{
- return 1; /* in wait_threads */
-}
-
int
main ()
{
int res;
long i;
+ alarm (300);
+
pthread_barrier_init (&barrier, NULL, 2);
res = pthread_create (&child_thread, NULL, child_function, NULL);
pthread_barrier_wait (&barrier);
- wait_threads (); /* set wait-thread breakpoint here */
+
+ /* Use an infinite loop with no function calls so that "step" over
+ this line never finishes before the breakpoint in the other
+ thread triggers. That can happen if the step-over of thread 2 is
+ done with displaced stepping on a target that is always in
+ non-stop mode, as in that case GDB runs both threads
+ simultaneously. */
+ while (1); /* set wait-thread breakpoint here */
pthread_join (child_thread, NULL);
diff --git a/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp b/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp
index 52b59ec..b38f23b 100644
--- a/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp
+++ b/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp
@@ -59,9 +59,9 @@ proc do_test {displaced command} {
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. However, right where the step-over lands
+ # there's another breakpoint installed, which should trap and
+ # be reported to the user.
gdb_test "$command" "step-over here.*"
}
}
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 6cf97fb..34ba079 100644
--- a/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c
+++ b/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c
@@ -43,23 +43,26 @@ child_function (void *arg)
pthread_exit (NULL);
}
-static int
-wait_threads (void)
-{
- return 1; /* in wait_threads */
-}
-
int
main ()
{
int res;
long i;
+ alarm (300);
+
pthread_barrier_init (&barrier, NULL, 2);
res = pthread_create (&child_thread, NULL, child_function, NULL);
pthread_barrier_wait (&barrier);
- wait_threads (); /* set wait-thread breakpoint here */
+
+ /* Use an infinite loop with no function calls so that "step" over
+ this line never finishes before the watchpoint in the other
+ thread triggers. That can happen if the step-over of thread 2 is
+ done with displaced stepping on a target that is always in
+ non-stop mode, as in that case GDB runs both threads
+ simultaneously. */
+ while (1); /* set wait-thread breakpoint here */
pthread_join (child_thread, NULL);
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 89b66e5..7e27f97 100644
--- a/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp
+++ b/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp
@@ -115,11 +115,10 @@ proc do_test { displaced with_bp } {
gdb_test "thread 1" "Switching to .*"
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, the
- # instruction that is under the breakpoint triggers a
- # watchpoint, which should trap and be reported to the
- # user.
+ # Thread 2 is still stopped at a breakpoint that needs
+ # to be stepped over. 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.*"
}
}
--
1.9.3
next prev parent reply other threads:[~2015-04-17 10:45 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-17 10:47 [PATCH v3 00/23] All-stop on top of non-stop Pedro Alves
2015-04-17 10:45 ` [PATCH v3 04/17] Make thread_still_needs_step_over consider stepping_over_watchpoint too Pedro Alves
2015-04-17 10:45 ` Pedro Alves [this message]
2015-04-17 10:45 ` [PATCH v3 03/17] remote.c/all-stop: Implement TARGET_WAITKIND_NO_RESUMED and TARGET_WNOHANG Pedro Alves
2015-04-17 10:45 ` [PATCH v3 02/17] Change adjust_pc_after_break's prototype Pedro Alves
2015-04-17 10:45 ` [PATCH v3 06/17] Use keep_going in proceed and start_step_over too Pedro Alves
2015-04-22 5:09 ` Doug Evans
2015-04-22 22:22 ` Pedro Alves
2015-04-17 10:45 ` [PATCH v3 15/17] PPC64: Fix gdb.arch/ppc64-atomic-inst.exp with displaced stepping Pedro Alves
2015-04-21 11:21 ` Yao Qi
2015-04-22 20:04 ` Pedro Alves
2015-04-17 10:45 ` [PATCH v3 05/17] Embed the pending step-over chain in thread_info objects Pedro Alves
2015-04-21 8:28 ` Yao Qi
2015-04-22 20:14 ` Pedro Alves
2015-04-21 9:53 ` Yao Qi
2015-04-22 19:07 ` Pedro Alves
2015-04-22 4:25 ` Doug Evans
2015-04-22 22:19 ` Pedro Alves
2015-04-17 10:45 ` [PATCH v3 11/17] Fix signal-while-stepping-over-bp-other-thread.exp on targets always in non-stop Pedro Alves
2015-04-17 10:45 ` [PATCH v3 08/17] Factor out code to re-resume stepped thread Pedro Alves
2015-04-17 10:47 ` [PATCH v3 01/17] Fix and test "checkpoint" in non-stop mode Pedro Alves
2015-04-21 2:36 ` Doug Evans
2015-04-22 17:48 ` Pedro Alves
2015-04-28 18:18 ` Doug Evans
2015-04-29 4:56 ` Doug Evans
2015-05-19 18:08 ` Pedro Alves
2015-04-17 10:47 ` [PATCH v3 07/17] Misc switch_back_to_stepped_thread cleanups Pedro Alves
2015-04-21 9:50 ` Yao Qi
2015-04-22 20:04 ` Pedro Alves
2015-04-22 5:23 ` Doug Evans
2015-04-22 20:05 ` Pedro Alves
2015-04-28 20:28 ` Doug Evans
2015-04-17 10:47 ` [PATCH v3 17/17] native Linux: enable always non-stop by default Pedro Alves
2015-04-17 10:52 ` [PATCH v3 12/17] Fix interrupt-noterm.exp on targets always in non-stop Pedro Alves
2015-04-21 11:40 ` Yao Qi
2015-04-22 20:03 ` Pedro Alves
2015-04-17 10:52 ` [PATCH v3 09/17] Teach non-stop to do in-line step-overs (stop all, step, restart) Pedro Alves
2015-04-17 11:01 ` Pedro Alves
2015-04-21 15:01 ` Yao Qi
2015-04-22 20:03 ` Pedro Alves
2015-04-24 9:06 ` Yao Qi
2015-04-27 20:17 ` Doug Evans
2015-05-19 18:09 ` Pedro Alves
2015-05-19 18:49 ` Pedro Alves
2015-04-17 10:56 ` [PATCH v3 14/17] Disable displaced stepping if trying it fails Pedro Alves
2015-04-17 11:06 ` [PATCH v3 16/17] S/390: displaced stepping and PC-relative RIL-b/RIL-c instructions Pedro Alves
2015-04-17 11:38 ` [PATCH v3 10/17] Implement all-stop on top of a target running non-stop mode Pedro Alves
2015-04-21 11:09 ` Yao Qi
2015-04-22 20:16 ` Pedro Alves
2015-04-24 7:39 ` Yao Qi
2015-05-19 18:08 ` Pedro Alves
2015-05-21 9:17 ` Yao Qi
2015-04-20 12:02 ` [PATCH v3 00/23] All-stop on top of non-stop Yao Qi
2015-04-20 16:54 ` Sergio Durigan Junior
2015-04-20 16:43 ` Pedro Alves
2015-04-21 7:48 ` Yao Qi
2015-04-21 15:05 ` Yao Qi
2015-04-22 22:27 ` Pedro Alves
2015-04-20 17:35 ` Simon Marchi
2015-05-19 18:14 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1429267521-21047-14-git-send-email-palves@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).