[0/17] RFC: share minimal symbols across objfiles

[Tom Tromey <tromey at redhat dot com>]

This patch series changes gdb to allow some sharing of data across
objfiles.  In particular this series adds sharing of minimal symbols.

The big idea here is that most data in an objfile is actually
independent of the inferior.  So, if multiple inferiors refer to the
data, we should be able to read it just once and then share.

This was discussed earlier:

    http://sourceware.org/ml/gdb-patches/2009-06/msg00668.html


I wanted to post this patch series to get some comments on it.  Although
it does pass regression testing, it is not ready to check in yet.  It
has a few hacks and a few FIXMEs, and one un-finished project.

One major problem with it right now is that because it duplicates the
demangled_names_hash, it probably requires more memory at runtime for
the single-inferior case than an unmodified gdb.  I haven't tried to
measure this.

The other major problem with this patch is that it makes it clear how
the BFD cache is fundamentally confused.

The BFD cache maintains a limited number of open file descriptors for
BFD objects.  (Right now this limit is hard coded as 10, which is
absurdly low.)  BFD will automatically close file descriptors and will
reopen the underlying file when needed.

However, GDB has its own logic for reopening files -- it notices when
the mtime has changed and will try to reread symbols at this point.

Now consider the case where you have two inferiors accessing the same
underlying file.  Suppose further that one inferior is running, and the
underlying file is changed and the user re-runs the second inferior.  If
the cache decides to reopen BFDs during this process, the first inferior
could try to access invalid data (depending on when the various debug
sections are mapped.)

Also there are comments in gdb indicating that the BFDs must be closed,
because on some operating systems keeping them open will mean that the
file cannot be exec'd.

In sum, it is a mess and I am not sure what to do about it.  Mapping all
the needed debug sections is possible, but slow, and in the
multi-inferior case that seems to be a recipe for running out of memory.
(But we can run out of memory anyway and probably need some approach for
fixing this...)


In contrast to my previous big patch, I split this one up as much as I
thought reasonably possible.  I haven't regtested all the patches
individually, but I will probably do that at some point.

Tom