gdb.threads/{siginfo-thread.c,watchthreads-reorder.c,ia64-sigill.c} races with GDB

gdb.threads/{siginfo-thread.c,watchthreads-reorder.c,ia64-sigill.c} races with GDB

These three test all spawn a few threads and then send a SIGSTOP to
their parent GDB in order to pause it while the new threads set things
up for the test.  With a GDB patch that changes the inferior thread's
scheduling a bit, I sometimes see:

  FAIL: gdb.threads/siginfo-threads.exp: catch signal 0 (timeout)
  ...
  FAIL: gdb.threads/watchthreads-reorder.exp: reorder1: continue a (timeout)
  ...
  FAIL: gdb.threads/ia64-sigill.exp: continue (timeout)
  ...

The issue is that the test program stops GDB before it had a chance of
processing the new thread's clone event:

  (gdb) PASS: gdb.threads/siginfo-threads.exp: get pid
  continue
  Continuing.
  Stopping GDB PID 21541.
  Waiting till the threads initialize their TIDs.
  FAIL: gdb.threads/siginfo-threads.exp: catch signal 0 (timeout)

On Linux (at least), new threads start stopped, and the debugger must
resume them.  The fix is to make the test program wait for the new
threads to be running before stopping GDB.

gdb/testsuite/
2015-01-09  Pedro Alves  <palves@redhat.com>

	* gdb.threads/ia64-sigill.c (threads_started_barrier): New global.
	(thread_func): Wait on barrier.
	(main): Wait for all threads to start before stopping GDB.
	* gdb.threads/siginfo-threads.c (threads_started_barrier): New
	global.
	(thread1_func, thread2_func): Wait on barrier.
	(main): Wait for all threads to start before stopping GDB.
	* gdb.threads/watchthreads-reorder.c (threads_started_barrier):
	New global.
	(thread1_func, thread2_func): Wait on barrier.
	(main): Wait for all threads to start before stopping GDB.