[gdb/testsuite] Add missing wait in gdb.multi/sched-multi-add-inferior.exp

With a gdb build with -O0 and Address Sanitizer and test-case
gdb.multi/sched-multi-add-inferior.exp, I get:
...
FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \
  continue to function1
FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \
  continue to function2
FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \
  continue to function1
FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \
  continue to function2
FAIL: $exp: target_type_1=native: target_type_2=native: continue to function1
FAIL: $exp: target_type_1=native: target_type_2=native: continue to function2
...

In more detail, for the target_type_1 == target_type_2 == native configuration,
we have:
...
(gdb) continue^M
Continuing.^M
[Switching to Thread 0x7ffff7cc02c0 (LWP 2514714)]^M
^M
Thread 2.1 "sched-multi-add" hit Breakpoint 4, main (...) at multi-target.c:94^M
94            function2 (); /* set break 2 here */^M
(gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \
  continue to function1
thread apply 2.1 set wait_for_gdb = 0^M
^M
Thread 2.1 (Thread 0x7ffff7cc02c0 (LWP 2514714) "sched-multi-add"):^M
(gdb) PASS: $exp: target_type_1=native: target_type_2=native: \
  thread apply 2.1 set wait_for_gdb = 0
continue^M
Continuing.^M
[Switching to Thread 0x7ffff7cc02c0 (LWP 2514718)]^M
^M
Thread 3.1 "sched-multi-add" hit Breakpoint 3, main (...) at multi-target.c:93^M
93            function1 (); /* set break 1 here */^M
(gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \
  continue to function2
...

The situation is as follows:
- there are two inferiors
- due to "set schedule-multiple on", continue continues both inferiors
- after the first continue, the test-case expects the breakpoint on thread 3.1
  to trigger
- instead, the breakpoint in thread 2.1 triggers

The mechanism by which this order is supposed to be guaranteed, is that thread
2.1 is blocked, and only unblocked after thread 3.1 hits its breakpoint:
...
    # Unblock thread 2.1 and continue again.  This time, thread 2.1
    # will hit a breakpoint.
    gdb_test "thread apply 2.1 set wait_for_gdb = 0" ".*"
...

However, thread 2.1 is never blocked.

Fix this by adding the missing:
...
    gdb_test "thread apply 2.1 set wait_for_gdb = 1" ".*"
...

Tested on x86_64-linux.

Approved-by: Kevin Buettner <kevinb@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33540

diff --git a/gdb/testsuite/gdb.multi/sched-multi-add-inferior.exp b/gdb/testsuite/gdb.multi/sched-multi-add-inferior.exp
index 03d502a3cf3b639c2d4644480c066c7ed4c0cffc..8be73ba44fa5a7c1ae5062a81742ba9dc79f75be 100644 (file)
--- a/gdb/testsuite/gdb.multi/sched-multi-add-inferior.exp
+++ b/gdb/testsuite/gdb.multi/sched-multi-add-inferior.exp
@@ -66,6 +66,10 @@ proc run_test { target_type_1 target_type_2 } {
        return 0
     }
 
+    # Block thread 2.1 from exiting function1, making sure that the breakpoint
+    # on the call to function2 won't trigger until we unblock the thread.
+    gdb_test "thread apply 2.1 set wait_for_gdb = 1" ".*"
+
     if {![add_inferior 3 $target_type_2 $::binfile]} {
        return 0
     }