This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: On resolving the MIPS gas branch reloc issue
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- Cc: Eric Christopher <echristo at redhat dot com>, binutils at sources dot redhat dot com
- Date: 04 Mar 2003 03:11:33 -0300
- Subject: Re: On resolving the MIPS gas branch reloc issue
- Organization: GCC Team, Red Hat
- References: <20030225092644.GE25303@rembrandt.csv.ica.uni-stuttgart.de><1046232750.2735.38.camel@ghostwheel.ges.redhat.com><20030226082807.GE16667@rembrandt.csv.ica.uni-stuttgart.de>
On Feb 26, 2003, Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de> wrote:
> The Embedded PIC ABI did something similiar earlier but with a GNU
> extension relocation. To keep compatible to it, we need now one new
> BFD_RELOC_MIPSEMB_16_PCREL_S2 bfd reloc, because BFD has no way to
> find out the ABI early enough.
Have you tested this heavily with n32 and/or n64? I ran into all
sorts of trouble because of weirdnesses such as the code next to the
following comments in gas/config/tc-mips.c:
/* In this case, the bfd_install_relocation routine will
incorrectly add the symbol value back in. We just want
the addend to appear in the object file.
howto->pcrel_offset is added for R_MIPS_PC16, which is
generated for code like
globl g1 .text
.text
.space 20
g1:
x:
bal g1
*/
/* Make sure the addend is still non-zero. If it became zero
after the last operation, set it to a spurious value and
subtract the same value from the object file's contents. */
/* This code was generated using trial and error and so is
fragile and not trustworthy. If you change it, you should
rerun the elf-rel, elf-rel2, and empic testcases and ensure
they still pass. */
/* BFD's REL handling, for MIPS, is _very_ weird.
This gives the right results, but it can't possibly
be the way things are supposed to work. */
/* If 'value' is zero, the remaining reloc code won't actually
do the store, so it must be done here. This is probably
a bug somewhere. */
All of these chunks assume REL relocations, and since n32 and n64 use
RELA, there's no way to generate appropriate relocations for certain
border values that trigger special conditions in the generic
relocation handling code. I tried very hard to fix them, but failed.
I wish the fix was this simple :-(
Perhaps we should just go with branches to symbols in the same
sections for now? Do you still have patch that you send me the other
day to that effect handy? Perhaps you could propose it here as well?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva at {redhat dot com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva at {lsd dot ic dot unicamp dot br, gnu.org}
Free Software Evangelist Professional serial bug killer