public inbox for bfd@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@zembu.com>
To: hjl@lucon.org
Cc: bfd@cygnus.com
Subject: Re: Mixing REL and RELA
Date: Thu, 15 Apr 1999 14:21:00 -0000	[thread overview]
Message-ID: <19990415212102.3383.qmail@daffy.airs.com> (raw)
In-Reply-To: <m10XtUI-000ErOC@ocean.lucon.org>

   From: hjl@lucon.org (H.J. Lu)
   Date: Thu, 15 Apr 1999 14:15:54 -0700 (PDT)

   > If REL works now, there is probably no reason to switch to RELA.  The
   > only reason I can think of would be if the compiler can gain an
   > advantage by splitting instructions which require relocations.  It is
   > sometime possible to make that work with REL instructions anyhow.
   > 
   > It would also be possible for the linker to support REL and RELA
   > relocations simultaneously, so there would be no need for a big
   > cutover.  We would just change gas to start generating RELA
   > relocations, and then after a while we could throw away the REL
   > support.
   > 
   > But I don't see a reason to do that if the code works now.

   Does the linker support mixing REL and RELA on any targets? How CPU
   depedent is this support? It may be useful to CPUs other than ARM.

I had this working at least for a little while for the 64 bit MIPS ELF
target, where the ABI from SGI requires it.  However, that target
never really worked, so I don't know how well mixing REL and RELA
works.

The support I wrote for MIPS is CPU dependent; the code is in
elf64-mips.c.  But I can't think of any reason why it has to be there.

Most relocation processing is CPU dependent anyhow, probably too much
so.

However, I would discourage mixing REL and RELA in object files.
That's just added complexity for no real benefit that I can see.

Ian

  reply	other threads:[~1999-04-15 14:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-15 10:38 arm questions Doug Evans
1999-04-15 11:01 ` Ian Lance Taylor
1999-04-15 11:31   ` Scott Bambrough
1999-04-15 11:47     ` Ian Lance Taylor
1999-04-15 13:29       ` H.J. Lu
1999-04-15 13:59         ` Ian Lance Taylor
1999-04-15 14:15           ` Mixing REL and RELA H.J. Lu
1999-04-15 14:21             ` Ian Lance Taylor [this message]
1999-04-15 14:28               ` H.J. Lu
1999-04-15 13:10   ` arm questions H.J. Lu
1999-04-15 13:45     ` Ian Lance Taylor
1999-04-15 13:36   ` Philip Blundell
1999-04-16  0:43     ` Lee Smith
1999-04-16  3:21       ` Toshi Morita
     [not found]     ` <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com>
1999-04-18 17:10       ` Doug Evans

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=19990415212102.3383.qmail@daffy.airs.com \
    --to=ian@zembu.com \
    --cc=bfd@cygnus.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).