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
