gdb/testsuite: remove perror calls when failing to run

gdb/testsuite: remove perror calls when failing to run

I noticed that when running these two tests in sequence:

    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
    ERROR: GDB process no longer exists
    ERROR: Couldn't run foo-all
    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...

The results in gdb.sum are:

    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
    PASS: gdb.ada/arrayptr.exp: scenario=all: compilation foo.adb
    ERROR: GDB process no longer exists
    UNRESOLVED: gdb.ada/arrayptr.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:40 (eof)
    ERROR: Couldn't run foo-all
    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...
    UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
    PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1

The UNRESOLVED for arrayptr.exp is fine, as GDB crashes in that test,
while trying to run to main.  However, the UNRESOLVED in assign_1.exp
doesn't make sense, GDB behaves as expected in that test:

    (gdb) set lang ada^M
    (gdb) UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
    print $xxx := 1^M
    $1 = 1^M
    (gdb) PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1

The problem is that arrayptr.exp calls perror when failing to run to
main, then returns.  perror makes it so that the next test (as in
pass/fail) will be recorded as UNRESOLVED.  However, here, the next test
(as in pass/fail) is in the next test (as in .exp).  Hence the spurious
UNRESOLVED in assign_1.exp.

These perror when failing to run to X are not really useful, especially
since runto records a FAIL on error, by default.  Remove all the
perrors on runto failure I could find.

When there wasn't one already, add a return statement when failing to
run, to avoid running the test of the test unnecessarily.

I thought of adding a check ran between test (in gdb_finish
probably) where we would emit a warning if errcnt > 0, meaning a test
quit and left a perror "active".  However, reading that variable would
poke into the DejaGNU internals, not sure it's a good idea.

Change-Id: I2203df6d06e199540b36f56470d1c5f1dc988f7b