[Top] [All Lists]

Re: Relocation problem with MIPS kernel modules

To: David VomLehn <>
Subject: Re: Relocation problem with MIPS kernel modules
From: Ralf Baechle <>
Date: Tue, 4 Aug 2009 00:55:36 +0100
Cc: David Daney <>, GCC Help Mailing List <>, Linux MIPS Mailing List <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
User-agent: Mutt/1.5.18 (2008-05-17)
On Mon, Aug 03, 2009 at 01:15:21PM -0700, David VomLehn wrote:

> > Actually I think it is the opposite:
> >
> > OFFSET   TYPE              VALUE
> > 00000000 R_MIPS_HI16       .bss+0x00000004
> > 00000008 R_MIPS_LO16       .bss+0x00000004
> > 00000014 R_MIPS_LO16       .bss+0x00000004
> >
> > We load the hi16 value into a register and then use multiple lo16  
> > offsets for the follow loads and stores to the same location.  On a  
> > read-modify-write we only want to load the base address one time.
> This particular case is covered by the old MIPS Processor psABI:
>       R_MIPS_LO16 entries without an R_MIPS_HI16 entry immediately preceding
>       are orphaned and the previously defined R_MIPS_HI16 is used for
>       computing the addend.
> The code in module.c looks like it implements the extension to which Ralf
> refers.

Which is useful for for branch delay slot scheduling like:

        j       1f
        lui     a0, %hi16(hello)
        j       1f
        lui     a0, %hi16(hello)
1:      jal     printf
        addiu   a0, %lo16(hello)

hello:  .asciz  "hello, hola\n"

The next and logical extension would be to permit multiple R_MIPS_LO16
records following a sequence of one or more R_MIPS_HI16 relocs as long as
all relate to the same symbol - which would be simple to support in the


<Prev in Thread] Current Thread [Next in Thread>