From: Tom de Vries Date: Sat, 10 Jan 2026 06:36:39 +0000 (+0100) Subject: [gdb/testsuite] Add missing wait in gdb.multi/sched-multi-add-inferior.exp X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=fa20c3de21cd86a90dfe94328626ce6730df3a63;p=thirdparty%2Fbinutils-gdb.git [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 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 03d502a3cf3..8be73ba44fa 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 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 }