Simon Marchi 30add7ee24 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		2022-12-05 16:38:24 -05:00
..
aout.sed
ecoff.sed
exclfwd1.c
exclfwd2.c
exclfwd.exp	gdb/testsuite: remove perror calls when failing to run	2022-12-05 16:38:24 -05:00
exclfwd.h
gdb11479.c
gdb11479.exp
hppa.sed
weird.def
weird.exp
xcoff.sed