]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/NEWS
gdb/python: add a new gdb_exiting event
authorAndrew Burgess <andrew.burgess@embecosm.com>
Tue, 7 Sep 2021 10:45:55 +0000 (11:45 +0100)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Tue, 5 Oct 2021 09:05:40 +0000 (10:05 +0100)
commitb1f0f2841871f407d116e3e7f0dfca3e410633d4
treeafec47062fce39a7b8973b7b5d48703803525a40
parent1cb56ad3f3bd378a5adde648c56c48b0a293e2b9
gdb/python: add a new gdb_exiting event

Add a new event, gdb.events.gdb_exiting, which is called once GDB
decides it is going to exit.

This event is not triggered in the case that GDB performs a hard
abort, for example, when handling an internal error and the user
decides to quit the debug session, or if GDB hits an unexpected,
fatal, signal.

This event is triggered if the user just types 'quit' at the command
prompt, or if GDB is run with '-batch' and has processed all of the
required commands.

The new event type is gdb.GdbExitingEvent, and it has a single
attribute exit_code, which is the value that GDB is about to exit
with.

The event is triggered before GDB starts dismantling any of its own
internal state, so, my expectation is that most Python calls should
work just fine at this point.

When considering this functionality I wondered about using the
'atexit' Python module.  However, this is triggered when the Python
environment is shut down, which is done from a final cleanup.  At
this point we don't know for sure what other GDB state has already
been cleaned up.
gdb/NEWS
gdb/doc/python.texi
gdb/observable.c
gdb/observable.h
gdb/python/py-all-events.def
gdb/python/py-event-types.def
gdb/python/python.c
gdb/testsuite/gdb.python/py-events.exp
gdb/testsuite/gdb.python/py-events.py
gdb/top.c