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

[Tom de Vries <tdevries@suse.de>]

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.

PR testsuite/33540
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33540
---
 gdb/testsuite/gdb.multi/sched-multi-add-inferior.exp | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/gdb/testsuite/gdb.multi/sched-multi-add-inferior.exp b/gdb/testsuite/gdb.multi/sched-multi-add-inferior.exp
index 03d502a3cf3..4530960dd24 100644
--- 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 untill 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
     }

base-commit: fc9bd3b1baffa2af37d494751012d25618fdede5
-- 
2.51.0