Query in MIPS HI and LO relocations

Query in MIPS HI and LO relocations

[Amarnath]

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.

Re: Query in MIPS HI and LO relocations

[Thiemo Seufer]

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.

The ELF ABI specifies this requirement. The GNU toolchain supports
somewhat relaxed rules which allow some optimisations.

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

Well, you can change it to anything you like, but it likely won't
be compatible any more. :-)
I recommend you stick with the model the GNU toolchain implements.


Thiemo

Re: Query in MIPS HI and LO relocations

[Eric Christopher]

On Apr 20, 2006, at 7:29 AM, 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.

You're free to do whatever you want. I'd look at some of the comments  
in elfxx-mips.c for guidance, e.g.

               /* The combined value is the sum of the HI16 addend,
                      left-shifted by sixteen bits, and the LO16
                      addend, sign extended.  (Usually, the code does
                      a `lui' of the HI16 value, and then an `addiu' of
                      the LO16 value.)

                      Scan ahead to find a matching LO16 relocation.

                      According to the MIPS ELF ABI, the R_MIPS_LO16
                      relocation must be immediately following.
                      However, for the IRIX6 ABI, the next relocation
                      may be a composed relocation consisting of
                      several relocations for the same address.  In
                      that case, the R_MIPS_LO16 relocation may occur
                      as one of these.  We permit a similar extension
                      in general, as that is useful for GCC.  */

-eric

RE: Query in MIPS HI and LO relocations

[Dave Korn]

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

RE: Query in MIPS HI and LO relocations

[Amarnath]

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