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: Wed, 30 Jun 2004 02:08:00 -0000	[thread overview]
Message-ID: <m3smcdajcg.fsf@gossamer.airs.com> (raw)
In-Reply-To: <40E1FF7A.10405@redhat.com>

Andrew Cagney <ac131313@redhat.com> writes:

> This follows up an earlier thread by adding the bfd_format type
> bfd_runtime.  It just pads out all the architecture vectors, not doing
> anything useful.

I'm sorry, I completely misunderstood what you were talking about
earlier.  I don't see why this is the right approach.  The fact that
file contents are stored in memory does not make that file any
different from a file stored on disk.  It is presumably still an
object file, and the contents of the file are presumably still
organized like an object file.  It seems to me that the format should
be bfd_object.

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.

I didn't read your earlier e-mail messages closely, and I thought that
what you were going to do was add a new iovec type.  That makes sense
to me.  I don't see why you need anything else.

If your only concern is to avoid requiring an ELF specific routine in
BFD, then the usual BFD approach is shown by bfd_get_gp_size() and
similar functions.  Those functions check the flavour, and then call
the appropriate backend routine.

Ian

  reply	other threads:[~2004-06-30  2:08 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 [this message]
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
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=m3smcdajcg.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).