@@ -50,8 +50,25 @@ if __name__ == '__main__':
inferior = subprocess.Popen(shlex.split(cmd))
# Now launch gdb with our test and collect the result
- gdb_cmd = "%s %s -ex 'target remote localhost:1234' -x %s" % (args.gdb, args.binary, args.test)
+ gdb_cmd = "%s %s" % (args.gdb, args.binary)
+ # run quietly and ignore .gdbinit
+ gdb_cmd += " -q -n -batch"
+ # disable prompts in case of crash
+ gdb_cmd += " -ex 'set confirm off'"
+ # connect to remote
+ gdb_cmd += " -ex 'target remote localhost:1234'"
+ # finally the test script itself
+ gdb_cmd += " -x %s" % (args.test)
+
+ print("GDB CMD: %s" % (gdb_cmd))
result = subprocess.call(gdb_cmd, shell=True);
+ # A negative result is the result of an internal gdb failure like
+ # a crash. We force a return of 0 so we don't fail the test on
+ # account of broken external tools.
+ if result < 0:
+ print("GDB crashed? SKIPPING")
+ exit(0)
+
exit(result)
@@ -70,7 +70,6 @@ except (gdb.error, AttributeError):
try:
# These are not very useful in scripts
gdb.execute("set pagination off")
- gdb.execute("set confirm off")
# Run the actual tests
run_test()
@@ -71,7 +71,6 @@ except (gdb.error, AttributeError):
try:
# These are not very useful in scripts
gdb.execute("set pagination off")
- gdb.execute("set confirm off")
# Run the actual tests
run_test()
It seems older and non-multiarach aware GDBs might not fail gracefully when faced with something they don't know. For example when faced with a target XML for s390x the Ubuntu 18.04 gdb will generate an internal fault and prompt for a core dump. Work around this by invoking GDB in a more batch orientated way and then trying to filter out between test failures and gdb failures. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- tests/guest-debug/run-test.py | 19 ++++++++++++++++++- tests/tcg/aarch64/gdbstub/test-sve-ioctl.py | 1 - tests/tcg/aarch64/gdbstub/test-sve.py | 1 - 3 files changed, 18 insertions(+), 3 deletions(-) -- 2.20.1