Re: [rfa] Add bfd_runtime

[Andrew Cagney <ac131313 at redhat dot com>]

[back to this thread, sorry]

> Andrew Cagney <ac131313@redhat.com> writes:
>
>
> > > > > > >>> 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).
>
>
> I understand that it is laid out differently.  Since I don't think
> that is at all relevant, we are clearly failing to communicate.
>
> There are many different kinds of object files, ELF and otherwise.
> They are all laid out differently.  They all have the same sorts of
> information.  From BFD's perspective, anything with that sort of
> information is properly categorized as bfd_object.
>
> The information which you are describing has the sort of information
> which an object file has.  From BFD's perspective, it seems to me that
> it should be bfd_object.
>
> If the layout is sufficiently different, then perhaps the problem is
> that is should use a different target vector--it should be
> "elfmem32-i386" rather than "elf32-i386".  But I can not understand
> why a different layout would suggest not using bfd_object.
>
> Let me put it another way: can you explain what the difference is
> between bfd_object and bfd_runtime, in terms of the difference between
> bfd_object and bfd_archive and bfd_core.

In terms of the relationships between various so called "format"s, I 
view things along the lines of:
	objfile is-a object is-a bfd
	runtime is-a object is-a bfd
	corefile is-a object is-a bfd
yet:
	bfd_archive is-a bfd
	bfd_archive has-a 1:N <object-file>
so BFD's currrent structure doesn't show real consistency :-/
(Relationships such as bfd_core is-a bfd_runtime don't hold.)

When it comes to how it should fit in, I think it can be viewed as:
	elf-target has-a runtime-object
	elf-target has-a corefile-object
	elf-target has-a objfile-object
and:
	elf32-i386 is-a elf-target
Hence, I think runtime fits better into the "format" vector as that 
makes that relationship possible.  Yes, it is also possible to 
brute-force this using "elfmem32-i386" et.al. targets.

Andrew

> > > > > > > > >>>> > 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 don't.  My point was that even talking about the question doesn't
> make any sense.  My implied conclusion was that bfd_runtime is not a
> proper format type.
>
> Ian