Andrew Burgess
59912fb2d2
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: <gdb.Progspace object at 0x7fb7e1d19c10> 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 <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.