Re: [rfa] Add bfd_runtime

[Andrew Cagney <ac131313@redhat.com>]

> Andrew Cagney <ac131313@redhat.com> 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
> 
> 
> Yes.
> 
> 
>>> 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.

Right.

Andrew