aboutsummaryrefslogtreecommitdiff
path: root/config-ml.in
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-08-28 16:22:36 +0100
committerAndrew Burgess <aburgess@redhat.com>2023-09-28 15:33:13 +0100
commit42f297ad36a13a7774fede3a8119e6c56ef6d318 (patch)
tree9d5ef57d0ec2eb14ce05975b670e8fce7628c99e /config-ml.in
parent063453b199e1291a03ee81c3422c31d7cca60af6 (diff)
downloadgdb-42f297ad36a13a7774fede3a8119e6c56ef6d318.zip
gdb-42f297ad36a13a7774fede3a8119e6c56ef6d318.tar.gz
gdb-42f297ad36a13a7774fede3a8119e6c56ef6d318.tar.bz2
gdb/python: make the executable_changed event available from Python
This commit makes the executable_changed observable available through the Python API as an event. There's nothing particularly interesting going on here, it just follows the same pattern as many of the other Python events we support. The new event registry is called events.executable_changed, and this emits an ExecutableChangedEvent object which has two attributes, a gdb.Progspace called 'progspace', this is the program space in which the executable changed, and a Boolean called 'reload', which is True if the same executable changed on disk and has been reloaded, or is False when a new executable has been loaded. One interesting thing did come up during testing though, you'll notice the test contains a setup_kfail call. During testing I observed that the executable_changed event would trigger twice when GDB restarted an inferior. However, the ExecutableChangedEvent object is identical for both calls, so the wrong information is never sent out, we just see one too many events. I tracked this down to how the reload_symbols function (symfile.c) takes care to also reload the executable, however, I've split fixing this into a separate commit, so see the next commit for details. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'config-ml.in')
0 files changed, 0 insertions, 0 deletions