Fix for PR 17247: Block SIGCHLD while initializing Guile.

The problem here is that if a thread other than gdb's main thread
gets a SIGCHLD (it's an asynchronous signal so the kernel will
essentially pick a random thread) then gdb will hang if it is
in sigsuspend when the SIGCHLD is delivered.  The other thread
will see the signal and the sigsuspend won't "wake up".

Guile and libgc should be blocking SIGCHLD in their threads,
but we need to work with Guile 2.0 and libgc 7.4.
The problem first shows up in libgc 7.4 because it is the first
release that enables multiple marker threads by default.

gdb/ChangeLog:

    	PR 17247
    	* guile.c: #include <signal.h>.
    	(_initialize_guile): Block SIGCHLD while initializing Guile.

    	Replaces the following, which is reverted.

    	2014-07-26  Doug Evans  <xdje42@gmail.com>

    	PR 17185
    	* configure.ac: Add check for header gc/gc.h.
    	Add check for function setenv.
    	* configure: Regenerate.
    	* config.in: Regenerate.
    	* guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.
PR guile/17367

gdb/ChangeLog:

	* acinclude.m4 (GDB_GUILE_PROGRAM_NAMES): Pass guile version as
	last parameter to pkg-config, not first.
	* configure.ac: Pass --with-guile provided pkg-config path to
	GDB_GUILE_PROGRAM_NAMES.
	* configure: Regenerate.
Automatic date update in version.in
testsuite: refactor spawn and wait for attach

Several places in the testsuite have a copy of a snippet of code that
spawns a test program, waits a bit, and then does some PID munging for
Cygwin.  This is in order to have GDB attach to the spawned program.

This refactors all that to a common procedure.

(multi-attach.exp wants to spawn multiple processes, so this makes the
new procedure's interface work with lists.)

Tested on x86_64 Fedora 20.

gdb/testsuite/ChangeLog:
2014-09-11  Pedro Alves  <palves@redhat.com>

	* lib/gdb.exp (spawn_wait_for_attach): New procedure.
	* gdb.base/attach.exp (do_attach_tests, do_call_attach_tests)
	(do_command_attach_tests): Use spawn_wait_for_attach.
	* gdb.base/solib-overlap.exp: Likewise.
	* gdb.multi/multi-attach.exp: Likewise.
	* gdb.python/py-prompt.exp: Likewise.
	* gdb.python/py-sync-interp.exp: Likewise.
	* gdb.server/ext-attach.exp: Likewise.
gdb/17347 - Regression: GDB stopped on run with attached process

Doing:

  gdb --pid=PID -ex run

Results in GDB getting a SIGTTIN, and thus ending stopped.  That's
usually indicative of a missing target_terminal_ours call.

E.g., from the PR:

 $ sleep 1h & p=$!; sleep 0.1; gdb -batch sleep $p -ex run
 [1] 28263
 [1]   Killed                  sleep 1h

 [2]+  Stopped                 gdb -batch sleep $p -ex run

The workaround is doing:

 gdb -ex "attach $PID" -ex "run"

instead of

 gdb [-p] $PID -ex "run"

With the former, gdb waits for the attach command to complete before
moving on to the "run" command, because the interpreter is in sync
mode at this point, within execute_command.  But for the latter,
attach_command is called directly from captured_main, and thus misses
that waiting.  IOW, "run" is running before the attach continuation
has run, before the program stops and attach completes.  The broken
terminal settings are just one symptom of that.  Any command that
queries or requires input results in the same.

The fix is to wait in catch_command_errors (which is specific to
main.c nowadays), just like we wait in execute_command.

gdb/ChangeLog:
2014-09-11  Pedro Alves  <palves@redhat.com>

	PR gdb/17347
	* main.c: Include "infrun.h".
	(catch_command_errors, catch_command_errors_const): Wait for the
	foreground command to complete.
	* top.c (maybe_wait_sync_command_done): New function, factored out
	from ...
	(maybe_wait_sync_command_done): ... here.
	* top.h (maybe_wait_sync_command_done): New declaration.

gdb/testsuite/ChangeLog:
2014-09-11  Pedro Alves  <palves@redhat.com>

	PR gdb/17347
	* lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure.
	* gdb.base/attach.exp (test_command_line_attach_run): New
	procedure.
	(top level): Call it.
Automatic date update in version.in
Merge remote-tracking branch 'gnu/gdb-7.8-branch' into 7.8