public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@airs.com>
To: "H. J. Lu" <hjl@lucon.org>
Cc: binutils@sources.redhat.com
Subject: Re: RFC: Remove output_target in ld
Date: Mon, 22 May 2006 08:57:00 -0000	[thread overview]
Message-ID: <m3lksupw6d.fsf@gossamer.airs.com> (raw)
In-Reply-To: <20060522002815.GA17421@lucon.org>

"H. J. Lu" <hjl@lucon.org> writes:

> On Sun, May 21, 2006 at 03:30:02PM -0700, H. J. Lu wrote:
> > ld has both output_target and ld_emulation, which has a target_name
> > field. Both of them are supposed to specify the output target name.
> > However, they aren't consistent, especially when a linker supports
> > different endians. Why do we need output_target? Can we set
> > ld_emulation correctly and use ld_emulation->target_name to replace
> > output_target. Also ld supports the GNUTARGET enviroment variable.
> > But we don't use it to set ld_emulation. I'd like to modify ld to
> > make ld_emulation consistent:
> > 
> > 1. Initialize ld_emulation properly with
> >    a. GNUTARGET.
> >    b. -m EMULATION.
> >    and correct endian, based on -EL/-BL.
> > 2. Use ld_emulation->target_name to identify the output target.
> > 
> 
> I realized that emulation may be just a subset of supported targets.
> Can we generate little endian ELF with big endian emulation? If yes,
> how do we do it?

The MIPS targets do this, for example.  If you configure for mips-elf,
the emulation is elf32ebmip.  That defaults to big-endian.  If you
trace the emulparams file, you will find this:

SCRIPT_NAME=elf
OUTPUT_FORMAT="elf32-bigmips"
BIG_OUTPUT_FORMAT="elf32-bigmips"
LITTLE_OUTPUT_FORMAT="elf32-littlemips"

Then elf.sc does this:

test -z "${BIG_OUTPUT_FORMAT}" && BIG_OUTPUT_FORMAT=${OUTPUT_FORMAT}
test -z "${LITTLE_OUTPUT_FORMAT}" && LITTLE_OUTPUT_FORMAT=${OUTPUT_FORMAT}
...
OUTPUT_FORMAT("${OUTPUT_FORMAT}", "${BIG_OUTPUT_FORMAT}",
	      "${LITTLE_OUTPUT_FORMAT}")

The three argument OUTPUT_FORMAT specifies which output format to use
if -EB or -EL is explicitly specified.

So, yes, there are more output targets than there are emulations.

Originally there were only supposed to be a couple of emulations.  But
then we would up specifying all sorts of things in the emulation, like
the default text addresses.  We didn't have to put stuff like that in
the emulation for the a.out object file format, in which addresses are
implied.  So now it's true that every new target tends to add a new
emulation.  But that wasn't the original plan.

Ian

      reply	other threads:[~2006-05-22  3:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-22  8:45 H. J. Lu
2006-05-22  8:49 ` H. J. Lu
2006-05-22  8:57   ` Ian Lance Taylor [this message]

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=m3lksupw6d.fsf@gossamer.airs.com \
    --to=ian@airs.com \
    --cc=binutils@sources.redhat.com \
    --cc=hjl@lucon.org \
    /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).