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

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.

0 files changed, 0 insertions, 0 deletions