Re: Relocation problem with MIPS kernel modules

[David VomLehn <dvomlehn@cisco.com>]

On Tue, Aug 04, 2009 at 12:55:36AM +0100, Ralf Baechle wrote:
> On Mon, Aug 03, 2009 at 01:15:21PM -0700, David VomLehn wrote:
> 
> > > Actually I think it is the opposite:
> > >
> > > RELOCATION RECORDS FOR [.text]:
> > > 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
> kernel.

This is what the orphaned R_MIPS_LO16 entries mentioned in the psABI quote
are all about. The existing relocation code handles this in most cases, but
could be juiced up a bit to do the check to verify the symbols match between
the current R_MIPS_LO16 entry and the last R_MIPS_HI16 entry.

>   Ralf

David VomLehn