public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@wasabisystems.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: binutils@sources.redhat.com
Subject: Re: [rfa] Add bfd_runtime
Date: Tue, 13 Jul 2004 02:38:00 -0000	[thread overview]
Message-ID: <m3hdsc1vij.fsf@gossamer.airs.com> (raw)
In-Reply-To: <40EAAF53.8070001@redhat.com>

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.

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

  reply	other threads:[~2004-07-13  2:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-29 23:47 Andrew Cagney
2004-06-30  2:08 ` Ian Lance Taylor
2004-06-30 14:18   ` Andrew Cagney
2004-06-30 14:36     ` Ian Lance Taylor
2004-07-06 13:55       ` Andrew Cagney
2004-07-13  2:38         ` Ian Lance Taylor [this message]
2004-09-20 23:14           ` Andrew Cagney
2004-09-21  0:57             ` Ian Lance Taylor
2004-09-21  1:38               ` DJ Delorie
2004-10-06 22:56                 ` Andrew Cagney
2004-09-21  8:38               ` Andreas Schwab
2004-10-06 23:22               ` Andrew Cagney
2004-10-07  5:16                 ` Ian Lance Taylor
2004-10-07 15:15                   ` Daniel Jacobowitz
2004-10-07 15:54                     ` Ian Lance Taylor
2004-10-07 19:12                   ` Andrew Cagney
2004-10-08  2:04                     ` Ian Lance Taylor
2004-10-07 16:48 James Cownie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3hdsc1vij.fsf@gossamer.airs.com \
    --to=ian@wasabisystems.com \
    --cc=ac131313@redhat.com \
    --cc=binutils@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).