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

[Ian Lance Taylor <ian at wasabisystems dot com>]

Andrew Cagney <cagney@gnu.org> writes:

> - is the theory ok?

Looks good to me.

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

Seems reasonable.  It's an additional function call, but most of those
functions hit the kernel anyhow so the additional cost should be
irrelevant.

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

I believe that some people do use mmap, so we shouldn't ignore this
for too long.

(mmap is disabled by default because after it was put in, it didn't
make things any faster.  That was a long ago, though, so it would be
appropriate for somebody to recheck it.)


I'm not crazy about the name bfd_fopen, since the function is not at
all synonymous with fopen().

While we're thinking about this, I think it would be nice to take
bfd_stat() and bfd_stat_arch_elt() out of the public interface, so
that a dynamic library doesn't have a dependency on the details of the
stat structure.  We can replace them with functions to retrieve the
specific information--generally just the size and mtime are wanted,
though ar also needs the mode.  We could also have a function to
return the underlying fileno for callers who really need it.

Ian