diff mbox series

[PULL,25/25] tests/guest-debug: better handle gdb crashes

Message ID 20220420180832.3812543-26-alex.bennee@linaro.org
State Accepted
Commit caccf599181e2ea5f236345de9d9957a4c23e5ec
Headers show
Series [PULL,01/25] tests/avocado: update aarch64_virt test to exercise -cpu max | expand

Commit Message

Alex Bennée April 20, 2022, 6:08 p.m. UTC 
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.bennee@linaro.org>
Reported-by: Gautam Agrawal <gautamnagrawal@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220419091020.3008144-26-alex.bennee@linaro.org>
diff mbox series

Patch

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)