[pushed] gdb.threads/manythreads.exp: clean up and add comment

[Pedro Alves <palves at redhat dot com>]

In git b57bacec, I said:

> With that in place, the need to delay "Program received signal FOO"
> was actually caught by the manythreads.exp test.  Without that bit, I
> was getting:
>
>   [Thread 0x7ffff7f13700 (LWP 4499) exited]
>   [New Thread 0x7ffff7f0b700 (LWP 4500)]
>   ^C
>   Program received signal SIGINT, Interrupt.
>   [New Thread 0x7ffff7f03700 (LWP 4501)]           <<< new output
>   [Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
>   __GI___nptl_death_event () at events.c:31
>   31      {
>   (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
>
> That is, I was now getting "New Thread" lines after the "Program
> received signal" line, and the test doesn't expect them.  As the
> number of new threads discovered before and after the "Program
> received signal" output is unbounded, it's much nicer to defer
> "Program received signal" until after synching the thread list, thus
> close to the "switching to thread" output and "current frame/source"
> info:
>
>   [Thread 0x7ffff7863700 (LWP 7647) exited]
>   ^C[New Thread 0x7ffff786b700 (LWP 7648)]
>
>   Program received signal SIGINT, Interrupt.
>   [Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
>   __GI___nptl_create_event () at events.c:25
>   25      {
>   (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1

This commit factors out the two places in the test that are effected
by this, and adds there a destilled version of the comment above.

gdb/testsuite/
2014-10-02  Pedro Alves  <palves@redhat.com>

	* gdb.threads/manythreads.exp (interrupt_and_wait): New procedure.
	(top level) <stop threads 1, stop threads 2>: Use it.
---
 gdb/testsuite/ChangeLog                   |  5 ++
 gdb/testsuite/gdb.threads/manythreads.exp | 83 +++++++++++++++++++------------
 2 files changed, 56 insertions(+), 32 deletions(-)

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 3579660..255e856 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,5 +1,10 @@
 2014-10-02  Pedro Alves  <palves@redhat.com>
 
+	* gdb.threads/manythreads.exp (interrupt_and_wait): New procedure.
+	(top level) <stop threads 1, stop threads 2>: Use it.
+
+2014-10-02  Pedro Alves  <palves@redhat.com>
+
 	* gdb.threads/break-while-running.exp (test): Add new
 	'update_thread_list' argument.  Skip "info threads" if false.
 	(top level): Add new 'update_thread_list' axis.
diff --git a/gdb/testsuite/gdb.threads/manythreads.exp b/gdb/testsuite/gdb.threads/manythreads.exp
index 9431b01..c35d6ab 100644
--- a/gdb/testsuite/gdb.threads/manythreads.exp
+++ b/gdb/testsuite/gdb.threads/manythreads.exp
@@ -55,24 +55,58 @@ gdb_test_multiple "continue" "first continue" {
 # we don't lose GDB's output while we do it.
 remote_expect host 1 { timeout { } }
 
-# Send a Ctrl-C and verify that we can do info threads and continue
-send_gdb "\003"
-set message "stop threads 1"
-gdb_test_multiple "" "stop threads 1" {
-  -re "\\\[New \[^\]\]*\\\]\r\n" {
-    exp_continue
-  }
-  -re "\\\[\[^\]\]* exited\\\]\r\n" {
-    exp_continue
-  }
-  -re "Program received signal SIGINT.*$gdb_prompt $" {
-    pass "$message"
-  }
-  timeout {
-    fail "$message (timeout)"
-  }
+# Send a Ctrl-C and wait for the SIGINT.
+
+proc interrupt_and_wait { message } {
+    global gdb_prompt
+
+    send_gdb "\003"
+
+    gdb_test_multiple "" $message {
+	-re "\\\[New \[^\]\]*\\\]\r\n" {
+	    exp_continue
+	}
+	-re "\\\[\[^\]\]* exited\\\]\r\n" {
+	    exp_continue
+	}
+	-re "Program received signal SIGINT.*$gdb_prompt $" {
+	    pass "$message"
+	}
+	-re "$gdb_prompt $" {
+	    # Note that with this regex order, if GDB emits [New
+	    # Thread ...] output between "Program received signal" and
+	    # the prompt, the "Program received signal" regex won't
+	    # match.  That's good, as if we see that happening, it's a
+	    # regression.
+	    #
+	    # GDB makes sure to notify about signal stops, end of
+	    # stepping ranges, etc., only after updating the thread
+	    # list, otherwise that stop info would be easy to miss.
+	    #
+	    # A BROKEN example would be:
+	    #
+	    #  ... pages of new threads output ...
+	    #  [New Thread NNN]
+	    #  ^C
+	    #  ... more new threads output ...
+	    #  [New Thread NNN]
+	    #  [New Thread NNN]
+	    #  Program received signal SIGINT, Interrupt.
+	    #  [New Thread NNN]
+	    #  [New Thread NNN]
+	    #  ... pages of new threads output ...
+	    #  [Switching to Thread NNN]
+	    #  foo () at foo.c:31
+	    #  31      bar ();
+	    #
+	    fail $test
+	}
+    }
 }
 
+# Send a Ctrl-C and verify that we can do info threads and continue
+interrupt_and_wait "stop threads 1"
+
 set cmd "info threads"
 set ok 0
 gdb_test_multiple $cmd $cmd {
@@ -132,22 +166,7 @@ remote_expect host 1 {
 }
 
 # Send another Ctrl-C and verify that we can do info threads and quit
-send_gdb "\003"
-set message "stop threads 2"
-gdb_test_multiple "" "stop threads 2" {
-  -re "\\\[New \[^\]\]*\\\]\r\n" {
-    exp_continue
-  }
-  -re "\\\[\[^\]\]* exited\\\]\r\n" {
-    exp_continue
-  }
-  -re "Program received signal SIGINT.*$gdb_prompt $" {
-    pass "$message"
-  }
-  timeout {
-    fail "$message (timeout)"
-  }
-} 
+interrupt_and_wait "stop threads 2"
 
 gdb_test_multiple "quit" "GDB exits after stopping multithreaded program" {
     -re "Quit anyway\\? \\(y or n\\) $" {
-- 
1.9.3