This is the mail archive of the
mailing list for the binutils project.
Re: R_MIPS_PC16 relocation handling, a proposal
- To: macro at ds2 dot pg dot gda dot pl
- Subject: Re: R_MIPS_PC16 relocation handling, a proposal
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 13 Oct 1999 00:01:59 -0400
- CC: binutils at sourceware dot cygnus dot com
- References: <Pine.GSO.3.96.991011194026.10449G-100000@delta.DS2.net>
Date: Tue, 12 Oct 1999 18:41:07 +0200 (MET DST)
From: "Maciej W. Rozycki" <email@example.com>
Guessing from MIPS ISA and ABI documents it seems there is no much use of
R_MIPS_PC16 relocations. On the other hand, the b* branch opcode family
uses a shifted by two bits 16-bit PC-relative field that is not handled by
any of MIPS relocations. I think the authors of ABI might just missed the
fact of the shift when documenting R_MIPS_PC16.
Anyway, I propose using R_MIPS_PC16 for BFD_RELOC_16_PCREL_S2 relocations
which would allow object modules to contain external references from b*
opcodes. As R_MIPS_PC16 is pretty unusable at the moment, nothing should
break. Otherwise, we might create a BFD-specific extension (just like
e.g. R_386_PC8 for i386).
The ABI defines R_MIPS_PC16. Our implementation should match the ABI.
We can't argue that the ABI got it wrong and implement it differently;
we will fail to interoperate with other implementations.
I don't know why the ABI defines R_MIPS_PC16 the way it does, but I
doubt the authors made such a simple mistake. ELF ABIs traditionally
only define the relocations needed to dynamically link programs on a
Unix system. The 16 bit branch can not be used between object files
in an ordinary Unix program, because there is no way to guarantee that
it will not overflow.