This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa] Add bfd_runtime

Andrew Cagney <> writes:

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

Sure.  But it is still essentially an object-file/executable.  At
least, I thought that was the idea of the in-memory image: that it
would look like an object-file/executable, it would have symbols and
sections and segments, etc.

It has symbols and sections and segments but is laid out very differently. Things are accessed according to their in-memory rather than on-disk offset. (however the current code doesn't do this, it reverse engineers things back into what is kind of sort of an on disk image).

> 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 don't understand this question.

Creating a new bfd is a two step process:
- open the raw file
- check the format creating a bfd from the raw file
The second step, using bfd_check_format, typically includes an explicit format specifier.

For this "runtime", the code needs to know that it is manipulating a loaded, rather than on-disk image. Without that it won't know that the load rather than file offsets need to be used.

So given that the code needs to be explicitly told that it is a runtime, why do you see the need to recognize a bfd_runtime rather than bfd_object?

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

Let's not start thinking that we will ever have to do this for
anything other than ELF.  Even if we some day do, we can still handle
via the bfd_get_gp_size() approach.

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

This assumes that there is already a bfd against which the flavour can be checked - and and more are a problem. What we're ment to be doing is creating a new bfd starting from scratch using information extracted from the images header. _bfd_elf,bfd_from_remote_memory doesn't do this, instead assuming the caller already knows what the image will be supplying it in TEMPL.

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.

It seems to me that the proper iovec routines could handle this
without copying the contents.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]