Re: [wip] BFD from an arbitrary object; Was: provide pass-through valuein bfd_elf_bfd_from_remote_memory

[DJ Delorie <dj at redhat dot com>]

> - is the theory ok?

I like the theory.

> - given there are N equally effective ways of implementing the "struct 
> bfd_file" object, is the attached reasonable?

IMHO the right way to do it is to define a "base class" struct, with
only common elements (starting with int length and struct ops*), and
let the I/O module create a derived structure with extra fields if it
needs it.  I don't like the "void *cookie" solution because (1) you
get an additional pointer dereferencing cost, and (2) you get an extra
set of malloc/free overhead.

The ops structure should have a length field at the beginning, to
detect incompatible ABI versions.

Also, I would prefer the structures to be private to bfd, else
long-term compatibility issues arise.  Keep "shared libbfd.so" in mind
;-) I know, this means gdb can't use it.  Well, try to think of a way
to avoid compatibility issues in the future ;-)

Note that DLL support needs to create a writable bfd_in_memory, and
later switch it to a readable BIM and read it back, all without
touching the disk.  Basically, the linker creates some libraries in
memory then links against them.  The ops structure may need to know
about that.

> - what to do about mmap?
> I ignored it as it isn't enabled by default :-/  I personally think that 
> it should be let be until this is in and then BFD and GDB figure out how 
> exactly they both want mmap to work.

If we're hiding the I/O details, we just hide it.  We can add it later
if bfd detects that it's working.

> - do the changes to cache.c scare anyone (I've not checked them 
> carefully yet :-)?

I checked it out only a little; my only thought is that it should be
subservient to the file I/O bfd_file.  The days of heavily limited
systems is long past, I don't think we need to think about cache at
the high level any more.  Neither in-memory nor mmap ones need the
cache behind them (I assume that the OS will manage swapping mmaps in
and out as memory permits, if not, don't use mmap ;).