OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity

tests/guest-debug: better handle gdb crashes

Browse Source 
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>
This commit is contained in:
Alex Bennée 2022-04-19 10:10:20 +01:00
parent e618e1f9b4
commit caccf59918
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
tests/guest-debug/run-test.py
View File

@ -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)