mmap changes, mostly for aout right now

[raeburn@cygnus.com]

I've just checked in now some changes to bfd to use mmap for reading
files under certain circumstances.  A snapshot file should be available
within the next hour or so.  Please try it out and let me know of any
problems.

Currently the "certain circumstances" are limited to string and symbol
table reading for a.out formats, but the interfaces are available to
eventually be used by other formats as well.  There's some preliminary
code to support reading section contents via mmap, but it's not really
tested, and not used anywhere at the moment.  It's also not quite set up
right for optimal use by the linker; that'll take a little bit more work.

These changes add new interfaces for accessing file contents, where the
memory management is under the control of the BFD library rather than the
application.  This lets BFD determine whether mmap can be used or if
malloc/seek/read must be used, transparently to the application.

My tests on sun4 and linux(aout), using local disk, indicate some small
improvement using mmap compared with the old code, even though only
symbol and string tables are accessed this way.

Under NetBSD (on i386), I saw no significant change in CPU time used
(though my test case was different -- many more small files in and out of
libraries).  The linker does seem to work now, after a linker change I
checked in yesterday, based on some changes from Niklas Hallqvist; please
exercise that too.  The linker still takes about half again as much CPU
time as the system (pre-BFD) one, though the system one took more
wall-clock time in my tests than the BFD one, and the mmap changes
reduced the wall-clock time further still.  (I *think* the system was
otherwise idle, but there may have been some cron jobs running, so I
don't consider those last observations to necessarily be significant.)
The BFD linker can generate smaller `-g' executables than the pre-BFD one
due to the string table massaging it does.

Under Linux, using (a.out) object files read and stored over NFS, the
performance got worse using mmap.  My guess is that this is a Linux
problem.  I'm told the Linux NFS client code isn't particularly
spectacular, and I don't know what the mmap support is like.  Maybe some
use of madvise would help?

On host systems where mmap is not available, you'll get a slight
performance degradation compared with the older code.  But I think mmap
is likely to be available on most of the systems we care about these
days, so the tradeoff seems reasonable.

If mmap isn't available or doesn't work right on your system, and the
bfd/configure script doesn't detect that, please try to come up with a
test that does detect the problem.

There's still plenty of room for improving this code.  Using it in more
places, more efficient handling of mapping, perhaps mapping the entire
file in read-only, maybe using madvise, not modifying data in place after
it's mapped in, etc.

Like I said, let me know of any problems....

Ken