RE: Query in MIPS HI and LO relocations

["Dave Korn" <dave dot korn at artimi dot com>]

On 20 April 2006 15:29, Amarnath wrote:

> Hi all,
> 
> I am having a query in the MIPS ABI. As per the SYSTEM V ABI,
> R_MIPS_HI16 relocation should be immediately followed by its
> corresponding R_MIPS_LO16.
> 
> I would like to know whether this is specific to SYSTEM V architecture
> alone / the linker specification can be changed as per our own
> architecture.
> 
> Please help me in understanding this.

  It's in order to make life easier for the linker.  Because MIPS is a USE_REL
target, the reloc operands must be stored in the immediate operand field in
each instruction itself.  This means that there's only room for 16 bits of the
actual reloc in each instruction and the full relocation computation can't be
done without being able to link the two parts together and reassemble the full
32-bit reloc easily.

  See this extract from the bfd internals manual:

-------------------------------snip-------------------------------
If the format should use Rel rather than Rela relocations, define USE_REL.
This is normally defined in chapter 4 of the processor specific supplement. 

In the absence of a supplement, it's easier to work with Rela relocations.
Rela relocations will require more space in object files (but not in
executables, except when using dynamic linking). However, this is outweighed
by the simplicity of addend handling when using Rela relocations. With Rel
relocations, the addend must be stored in the section contents, which makes
relocateable links more complex. 

For example, consider C code like i = a[1000]; where a is a global array. The
instructions which load the value of a[1000] will most likely use a relocation
which refers to the symbol representing a, with an addend that gives the
offset from the start of a to element 1000. When using Rel relocations, that
addend must be stored in the instructions themselves. If you are adding
support for a RISC chip which uses two or more instructions to load an
address, then the addend may not fit in a single instruction, and will have to
be somehow split among the instructions. This makes linking awkward,
particularly when doing a relocateable link in which the addend may have to be
updated. It can be done--the MIPS ELF support does it--but it should be
avoided when possible. 
-------------------------------snip-------------------------------


  See also the comments on 'struct mips_hi_fixup' and on function
mips_frob_file() in /src/gas/config/tc-mips.c for more.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....