This is the mail archive of the
mailing list for the binutils project.
Re: [rfa] Add bfd_runtime
- From: Ian Lance Taylor <ian at wasabisystems dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: 12 Jul 2004 22:38:44 -0400
- Subject: Re: [rfa] Add bfd_runtime
- References: <40E1FF7A.email@example.com> <firstname.lastname@example.org><40E2CB85.email@example.com> <firstname.lastname@example.org><40EAAF53.email@example.com>
Andrew Cagney <firstname.lastname@example.org> 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
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.
> >>>> > 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.