gdb: add Python events for program space addition and removal

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: <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>