From caccf599181e2ea5f236345de9d9957a4c23e5ec Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alex=20Benn=C3=A9e?= Date: Tue, 19 Apr 2022 10:10:20 +0100 Subject: tests/guest-debug: better handle gdb crashes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Reported-by: Gautam Agrawal Reviewed-by: Richard Henderson Message-Id: <20220419091020.3008144-26-alex.bennee@linaro.org> --- tests/guest-debug/run-test.py | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'tests') diff --git a/tests/guest-debug/run-test.py b/tests/guest-debug/run-test.py index 2e58795..d865e46 100755 --- a/tests/guest-debug/run-test.py +++ b/tests/guest-debug/run-test.py @@ -92,17 +92,18 @@ if __name__ == '__main__': 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) -- cgit v1.1