[rfa] Add bfd_runtime

[Andrew Cagney]

[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