RE: Query in MIPS HI and LO relocations

["Amarnath" <amarnath at acmet dot com>]

Since I am getting the compiled->assembled output emitted in the
following pattern, linking process is failing to calculate the address
correctly.

Pattern
-------

hi relocation         - R_MIPS_HI16
sdaoff relocation     - R_MIPS_GPREL16
sdaoff relocation     - R_MIPS_GPREL16
lo relocation         - R_MIPS_LO16

The insertion of two other relocation in between the HI and LO is
causing the problem in calculating the correct address. When the two
relocations (HI and LO) are following immediately, it is getting linked
correctly.

Thanks for all your valuable information.


Regards,
Amarnath M


> -----Original Message-----
> From: Dave Korn [mailto:dave.korn@artimi.com]
> Sent: Thursday, April 20, 2006 8:08 PM
> To: 'Amarnath'; binutils@sources.redhat.com
> Subject: RE: Query in MIPS HI and LO relocations
> 
> 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....