old-cross-binutils/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.c
Pedro Alves d4569d7bc5 Fix step-over-{trips-on-watchpoint|lands-on-breakpoint}.exp race
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-08-07  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.
2015-08-07 17:26:21 +01:00

68 lines
1.8 KiB
C

/* This testcase is part of GDB, the GNU debugger.
Copyright 2014-2015 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
pthread_barrier_t barrier;
pthread_t child_thread;
volatile unsigned int counter = 1;
void *
child_function (void *arg)
{
pthread_barrier_wait (&barrier);
while (counter > 0)
{
counter++;
asm (" nop"); /* set breakpoint child here */
asm (" nop"); /* set breakpoint after step-over here */
usleep (1);
}
pthread_exit (NULL);
}
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);
/* 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);
exit (EXIT_SUCCESS);
}