Re: [rfa] Add bfd_runtime

[Ian Lance Taylor <ian at wasabisystems dot 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.

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

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

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

It's effectively the same thing, though, by looking at
bfd_elf_bfd_from_remote_memory():

  if (bfd_get_flavour (abfd) == bfd_target_elf_flavour)
    return ((*get_elf_backend_data (abfd)->elf_backend_bfd_from_remote_memory)
            (templ, ehdr_vma, loadbasep, target_read_memory));

Ian