This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [rfa] Add bfd_runtime
- From: Andrew Cagney <cagney at gnu dot org>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: Andrew Cagney <ac131313 at redhat dot com>, binutils at sources dot redhat dot com
- Date: Wed, 06 Oct 2004 19:21:50 -0400
- Subject: Re: [rfa] Add bfd_runtime
- References: <40E1FF7A.10405@redhat.com> <m3smcdajcg.fsf@gossamer.airs.com> <40E2CB85.2030607@redhat.com> <m33c4d6rki.fsf@gossamer.airs.com> <40EAAF53.8070001@redhat.com> <m3hdsc1vij.fsf@gossamer.airs.com> <414F63A3.2050009@redhat.com> <m3acvkzbff.fsf@gossamer.airs.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.
Let me see if I've got this:
objfile - iterate over sections
corefile - iterate over segments
archive - ???
For runtime, bfd_map_over_sections needs to do something different again
create a list of sections using offset information obtained from the
segment table.
That can either be done in two stages; reverse map in-memory segments to
on-disk image, open pseudo on-disk image as an object file; or a single
direct stage where the "sections" describe the in memory offsets.
The latter, which I think is an operation unlike any of the above, is
what I'm trying to implement.
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.
So how would you solve this problem? Given a memory access method and a
starting offset, construct a bfd containing a list of sections
constructed using both the segment and section information in the inferior?
Andrew