aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.python
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2024-09-24 16:45:27 +0200
committerTom de Vries <tdevries@suse.de>2024-09-24 16:45:27 +0200
commit6896412cde41009ad2c9e7dc49640696ee963b68 (patch)
tree7ddad254329380b7af8b5ccb2d3c0abdab68ef1a /gdb/testsuite/gdb.python
parent2299dfd4ba96c6852db862f6ec1b96880ecd6c0c (diff)
downloadbinutils-6896412cde41009ad2c9e7dc49640696ee963b68.zip
binutils-6896412cde41009ad2c9e7dc49640696ee963b68.tar.gz
binutils-6896412cde41009ad2c9e7dc49640696ee963b68.tar.bz2
[gdb] Handle SIGTERM in run_events
While reviewing "catch (...)" uses I came across: ... for (auto &item : local) { try { item (); } catch (...) { /* Ignore exceptions in the callback. */ } } ... This means that when an item throws a gdb_exception_forced_quit, the exception is ignored and following items are executed. Fix this by handling gdb_exception_forced_quit explicity, and immediately rethrowing it. I wondered about ^C, and couldn't decide whether current behaviour is ok, so I left this alone, but I made the issue explicit in the source code. As for the "catch (...)", I think that it should let a non-gdb_exception propagate, so I've narrowed it to "catch (const gdb_exception &)". My rationale for this is as follows. There seem to be a few ways that "catch (...)" is allowed in gdb: - clean-up and rethrow (basically the SCOPE_EXIT pattern) - catch and handle an exception from a call into an external c++ library Since we're dealing with neither of those here, we remove the "catch (...)". Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/testsuite/gdb.python')
0 files changed, 0 insertions, 0 deletions