Re: [rfa] Add bfd_runtime

[Ian Lance Taylor <ian at wasabisystems dot com>]

Andrew Cagney <ac131313@redhat.com> writes:

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

I think you are looking for the wrong sort of consistency.  For better
or worse, everything that BFD manipulates is a bfd.  There are
(currently) three types of BFD: object, archive, core.  The three
different types support fundamentally different operations.
  * object supports bfd_map_over_sections(), bfd_canonicalize_reloc(),
    etc., etc.
  * archive supports bfd_set_archive_head(),
    bfd_openr_next_archived_file(), etc.
  * core supports bfd_core_file_failing_command(),
    core_file_matches_executable_p(), etc.

(core also supports bfd_map_over_sections(), although it is a
different operation for core files than for object files.  In ELF, for
core, bfd_map_over_sections() maps over ELF segments, not ELF
sections.  In the traditional core file format,
bfd_map_over_sections() maps over information stored in struct user.
In both cases, there are special register sections which are nothing
like any section in an object file.)

In other words, the fact that everything is a BFD is misleading.  BFD
manipulates three fundamentally different types of files.  There are
obvious similarities between the file types--that is why they are all
BFDs--but there are significant differences which can not be
overlooked.

My understanding is that the runtime images which you are talking
about are just like object files.  They will support the same types of
operations, at least on the read side.  That is why I think the
correct bfd_format setting for runtime images is bfd_object.

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

I could just as easily, and, at least to my mind, just as justifiably,
say
    elf-target has-a object-file
    elf-target has-a executable-file
    elf-target has-a shared-library-file
and conclude that we should expand bfd_format to distinguish object
files, executables, and shared libraries.  After all, there are
obvious differences between object files, executable files, and shared
libraries, and I think those differences are just as profound as the
difference between a regular .o file and the runtime image of a .o
file.  So I don't buy this particular argument that you are making.

Ian