We already skip "attach" tests if the target board is remote, in
dejagnu's sense, as we use TCL's exec to spawn the program on the
build machine. We should also skip these tests if testing with
"target remote" or other stub-like targets where "attach" doesn't make
sense.
Add a helper procedure that centralizes the checks a test that needs
to spawn a program for testing "attach" and make all test files that
use spawn_wait_for_attach check it.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (can_spawn_for_attach): New procedure.
(spawn_wait_for_attach): Error out if can_spawn_for_attach returns
false.
* gdb.base/attach.exp: Use can_spawn_for_attach instead of
checking whether the target board is remote.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Use can_spawn_for_attach before the
tests that need to attach, instead of checking whether the target
board is remote at the top of the file.
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.
