There are a number of GDB's on various distros which fail fairly hard
when attempting to talk to a cross-arch guest. The previous attempt to
catch this was incorrect as the shell will deliver signals as 128+n.
Fix the detection and while we are it improve the logging we dump into
the test output.
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Reported-by: Gautam Agrawal <gautamnagra...@gmail.com>
---
tests/guest-debug/run-test.py | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/tests/guest-debug/run-test.py b/tests/guest-debug/run-test.py
index 2e58795a10..d865e46ecd 100755
--- a/tests/guest-debug/run-test.py
+++ b/tests/guest-debug/run-test.py
@@ -92,17 +92,18 @@ def log(output, msg):
result = subprocess.call(gdb_cmd, shell=True, stdout=output)
- # 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
+ # A result of greater than 128 indicates a fatal signal (likely a
+ # crash due to gdb internal failure). That's a problem for GDB and
+ # not the test so 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")
+ if result > 128:
+ log(output, "GDB crashed? (%d, %d) SKIPPING" % (result, result - 128))
exit(0)
try:
inferior.wait(2)
except subprocess.TimeoutExpired:
- print("GDB never connected? Killed guest")
+ log(output, "GDB never connected? Killed guest")
inferior.kill()
exit(result)
--
2.30.2
