From 59912fb2d22f8a4bb0862487f12a5cc65b6a013f Mon Sep 17 00:00:00 2001 From: Andrew Burgess Date: Tue, 19 Sep 2023 11:45:36 +0100 Subject: gdb: add Python events for program space addition and removal Initially I just wanted a Python event for when GDB removes a program space, I'm writing a Python extension that caches information for each program space, and need to know when I should discard entries for a particular program space. But, it seemed easy enough to also add an event for when GDB adds a new program space, so I went ahead and added both new events. Of course, we don't currently have an observable for program space addition or removal, so I first needed to add these. After that it's pretty simple to add two new Python events and have these trigger. The two new event registries are: events.new_progspace events.free_progspace These emit NewProgspaceEvent and FreeProgspaceEvent objects respectively, each of these new event types has a 'progspace' attribute that contains the relevant gdb.Progspace object. There's a couple of things to be mindful of. First, it is not possible to catch the NewProgspaceEvent for the very first program space, the one that is created when GDB first starts, as this program space is created before any Python scripts are sourced. In order to allow this event to be caught we would need to defer creating the first program space, and as a consequence the first inferior, until some later time. But, existing scripts could easily depend on there being an initial inferior, so I really don't think we should change that -- and so, we end up with the consequence that we can't catch the event for the first program space. The second, I think minor, issue, is that GDB doesn't clean up its program spaces upon exit -- or at least, they are not cleaned up before Python is shut down. As a result, any program spaces in use at the time GDB exits don't generate a FreeProgspaceEvent. I'm not particularly worried about this for my use case, I'm using the event to ensure that a cache doesn't hold stale entries within a single GDB session. It's also easy enough to add a Python at-exit callback which can do any final cleanup if needed. Finally, when testing, I did hit a slightly weird issue with some of the remote boards (e.g. remote-stdio-gdbserver). As a consequence of this issue I see some output like this in the gdb.log: (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 step FreeProgspaceEvent: warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. warning: cannot close "target:/lib64/libc.so.6": Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. do_parent_stuff () at py-progspace-events.c:41 41 ++global_var; (gdb) PASS: gdb.python/py-progspace-events.exp: step The 'FreeProgspaceEvent ...' line is expected, that's my test Python extension logging the event. What isn't expected are all the blocks like: warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. It turns out that this has nothing to do with my changes, this is just a consequence of reading files over the remote protocol. The test forks a child process which GDB stays attached too. When the child exits, GDB cleans up by calling prune_inferiors, which in turn can result in GDB trying to close some files that are open because of the inferior being deleted. If the prune_inferiors call occurs when the remote target is running (and in non-async mode) then GDB will try to send a fileio packet while the remote target is waiting for a stop reply, and the remote target will throw an error, see remote_target::putpkt_binary in remote.c for details. I'm going to look at fixing this, but, as I said, this is nothing to do with this change, I just mention it because I ended up needing to account for these warning messages in one of my tests, and it all looks a bit weird. Approved-By: Tom Tromey Reviewed-By: Eli Zaretskii --- gdb/observable.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'gdb/observable.c') diff --git a/gdb/observable.c b/gdb/observable.c index 33e5122..93a842e 100644 --- a/gdb/observable.c +++ b/gdb/observable.c @@ -72,6 +72,8 @@ DEFINE_OBSERVABLE (gdb_exiting); DEFINE_OBSERVABLE (connection_removed); DEFINE_OBSERVABLE (target_pre_wait); DEFINE_OBSERVABLE (target_post_wait); +DEFINE_OBSERVABLE (new_program_space); +DEFINE_OBSERVABLE (free_program_space); } /* namespace observers */ } /* namespace gdb */ -- cgit v1.1