Re: R_MIPS_PC16 relocation handling, a proposal

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

On 13 Oct 1999, Ian Lance Taylor wrote:

> 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.

 We may define a GNU extension, i.e. a different relocation for this
purpose -- it does not cost much.  One might say, using R_386_PC16 and
R_386_PC8 do not make sense on a Unix system, yet they exist and thus make
life simpler.  Note gcc do not generate any of these, so they are
definitely a result of a work of an assembly language programmer who
usually knows what are the limitations of the relevant opcodes and who
will not be surprised to see an overflow error if it's for a reason.

 Finally, please note that binutils need not be used for a Unix system --
the may be treated as a standalone suite of programs for generating
arbitrary binaries.  ELF is nice as a container due to it's flexibility
but the final image might be actually objcopied to "binary" and e.g. put
in some kind of ROM.

> 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.

 I am writing of a static relocation only, of course, that would be
resolved when creating an executable or a shared object.  It makes no
sense for dynamic linking, obviously.  But note that R_MIPS_26 is unsafe,
too, as one cannot guarantee the jump will not need to cross the 256 MB
boundary, yet the authors of the ABI did not hesitate to include it.

 Actually, the ECOFF backend already implements the R_MIPS_PC16 in the way
I am suggesting for ELF.

 And while writing of stupid errors -- the "A < 2" statement in the
description of R_MIPS_26 certainly does not make any sense at all, does
it?  But shouldn't we stick to ABI?  Well, I feel a bit unsafe with SCO
being the author of the ABI, all they know well is probably i386 (I hope,
that is), I am afraid.  The person who wrote the MIPS addendum might just
simply misread some part of MIPS specs and did not notice that the offset 
is being shifted for branches. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +