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