[gdb/testsuite] Fix another timeout in gdb.base/bg-execution-repeat.expHEADmaster

With test-case gdb.base/bg-execution-repeat.exp, occasionally I run into a
timeout:
...
(gdb) c 1&
Will stop next time breakpoint 1 is reached.  Continuing.
(gdb) PASS: $exp: c 1&: c 1&

Breakpoint 2, foo () at bg-execution-repeat.c:23
23        return 0; /* set break here */
PASS: $exp: c 1&: breakpoint hit 1

Will stop next time breakpoint 2 is reached.  Continuing.
(gdb) PASS: $exp: c 1&: repeat bg command
print 1
$1 = 1
(gdb) PASS: $exp: c 1&: input still accepted
interrupt
(gdb) PASS: $exp: c 1&: interrupt

Program received signal SIGINT, Interrupt.
foo () at bg-execution-repeat.c:24
24      }
PASS: $exp: c 1&: interrupt received
set var do_wait=0
(gdb) PASS: $exp: c 1&: set var do_wait=0
continue&
Continuing.
(gdb) PASS: $exp: c 1&: continue&
FAIL: $exp: c 1&: breakpoint hit 2 (timeout)
...

I can reproduce it reliably by adding a "sleep (1)" before the "do_wait = 1"
in the .c file.

The timeout happens as follows:
- with the inferior stopped at main, gdb continues (command c 1&)
- the inferior hits the breakpoint at foo
- gdb continues (using the repeat command functionality)
- the inferior is interrupted
- inferior variable do_wait gets set to 0.  The assumption here is that the
  inferior has progressed enough that do_wait is set to 1 at that point, but
  that happens not to be the case.  Consequently, this has no effect.
- gdb continues
- the inferior sets do_wait to 1
- the inferior enters the wait function, and wait for do_wait to become 0,
  which never happens.

Fix this by moving the "do_wait = 1" to before the first call to foo.

Tested on x86_64-linux.

Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

0 files changed, 0 insertions, 0 deletions