This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [rfa] Add bfd_runtime
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 30 Jun 2004 10:17:41 -0400
- Subject: Re: [rfa] Add bfd_runtime
- References: <40E1FF7A.10405@redhat.com> <m3smcdajcg.fsf@gossamer.airs.com>
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