gdb/testsuite: another attempt to fix gdb.threads/thread-specific-bp.exp

The gdb.threads/thread-specific-bp.exp test has been a little
problematic, see commits:

  commit 89702edd933a5595557bcd9cc4a0dcc3262226d4
  Date:   Thu Mar 9 12:31:26 2023 +0100

      [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver

and

  commit 2e5843d87c4050bf1109921481fb29e1c470827f
  Date:   Fri Nov 19 14:33:39 2021 +0100

      [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp

But I recently saw a test failure for that test, which looked like
this:

  ...
  (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected
  continue -a
  Continuing.

  Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
  29      }
  (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited]
  Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
  FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout)
  ...

This only crops up (for me) when running on a loaded machine, and
still only occurs sometimes.  I've had to leave the test running in a
loop for 10+ minutes sometimes in order to see the failure.

The problem is that we use gdb_test_multiple to try and match two
patterns:

  (1) The 'Thread-specific breakpoint 3 deleted ....' message, and
  (2) The GDB prompt.

As written in the test, we understand that these patterns can occur in
any order, and we have a flag for each pattern.  Once both patterns
have been seen then we PASS the test.

The problem is that once expect has matched a pattern, everything up
to, and including the matched text is discarded from the input
buffer.  Thus, if the input buffer contains:

  <PATTERN 2><PATTERN 1>

Then expect will first try to match <PATTERN 1>, which succeeds, and
then expect discards the entire input buffer up to the end of the
<PATTERN 1>.  As a result, we will never spot <PATTERN 2>.

Obviously we can't just reorder the patterns within the
gdb_test_multiple, as the output can legitimately (and most often
does) occur in the other order, in which case the test would mostly
fail, and only occasionally pass!

I think the easiest solution here is just to have the
gdb_test_multiple contain two patterns, each pattern consists of the
two parts, but in the alternative orders, thus, for a particular
output configuration, only one regexp will match.  With this change in
place, I no longer see the intermittent failure.

Approved-By: Tom Tromey <tom@tromey.com>

1 files changed, 6 insertions, 18 deletions

diff --git a/gdb/testsuite/gdb.threads/thread-specific-bp.exp b/gdb/testsuite/gdb.threads/thread-specific-bp.exp
index 8929f19..1f3b944 100644
--- a/gdb/testsuite/gdb.threads/thread-specific-bp.exp
+++ b/gdb/testsuite/gdb.threads/thread-specific-bp.exp
@@ -87,31 +87,19 @@ proc check_thread_specific_breakpoint {non_stop} {
     } else {
 	set cmd "continue"
     }
-    set test "continue to end"
-    set thread_exited 0
-    set prompt 0
     set msg_re \
 	[join \
 	     [list \
 		  "Thread-specific breakpoint 3 deleted" \
 		  "-" \
 		  "thread 2 no longer in the thread list\\."]]
-    gdb_test_multiple "$cmd" $test -lbl {
-	-re "(^|\r\n)${msg_re}(?=\r\n)" {
-	    if { $prompt } {
-		pass $gdb_test_name
-	    } else {
-		set thread_exited 1
-		exp_continue
-	    }
+
+    gdb_test_multiple "$cmd" "continue to end" {
+	-re "$\r\n${gdb_prompt} .*${msg_re}\r\n" {
+	    pass $gdb_test_name
 	}
-	-re "\r\n$gdb_prompt " {
-	    if { $thread_exited } {
-		pass $gdb_test_name
-	    } else {
-		set prompt 1
-		exp_continue
-	    }
+	-re "\r\n${msg_re}\r\n.*$gdb_prompt " {
+	    pass $gdb_test_name
 	}
     }