[rfa] Add bfd_runtime

[Andrew Cagney]

Here's the thread: New bfd file format bfd_image ....
http://sources.redhat.com/ml/binutils/2004-05/msg00049.html
http://sources.redhat.com/ml/binutils/2004-06/msg00002.html

> Andrew Cagney <ac131313@redhat.com> writes:
> 
> 
>>> This follows up an earlier thread by adding the bfd_format type
>>> bfd_runtime.  It just pads out all the architecture vectors, not doing
>>> anything useful.
> 
> 
> I'm sorry, I completely misunderstood what you were talking about
> earlier.  I don't see why this is the right approach.  The fact that
> file contents are stored in memory does not make that file any
> different from a file stored on disk.  It is presumably still an
> object file, and the contents of the file are presumably still
> organized like an object file.  It seems to me that the format should
> be bfd_object.

The contents are organized differently.  It's the in-memory runtime 
image so things are organized acccording to their load address and not 
their on-disk file offset.

> Thinking in terms of adding support for a new object file format to
> BFD, what would the entries for bfd_runtime be?  How can you recognize
> a file as bfd_runtime rather than bfd_object?  The concept of
> bfd_runtime seems to me to be orthogonal to the concept of bfd_format.

Do you need to differentiate between the two?

> I didn't read your earlier e-mail messages closely, and I thought that
> what you were going to do was add a new iovec type.  That makes sense
> to me.  I don't see why you need anything else.

Can you expand on what you mean here?  Are you suggesting the two step 
process:

- create an iovec that maps ``on-disk'' offsets onto ``in-memory'' 
offsets.  That way the client thinks its reading the on-disk image when 
it isn't.

- create a bfd_object using this iovec

That first operation is format dependant (as in the ELF, XCOFF, and 
a.out NMAGIC versions would all involve different code but the same 
basic operation).

> If your only concern is to avoid requiring an ELF specific routine in
> BFD, then the usual BFD approach is shown by bfd_get_gp_size() and
> similar functions.  Those functions check the flavour, and then call
> the appropriate backend routine.

The objective is to get a clean and efficient mechanism for examining 
shared library information from a running program.  vsyscall is one 
reason, gcj is expected to be a second.

The current code re-creates the bfd_object reading the entire contents 
into local memory and then uses that to create abfd-in-memory.  Not very 
efficient.

(BTW, bfd_get_gp_size doesn't _call_ a backend routine, it just refers 
to a back-end macro.  Is there another example?)

Andrew