Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

[Richard Sandiford <rsandifo@redhat.com>]

Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL> writes:
>> What do you mean?  I'm talking about reordering the relocations in
>> the .rel.foo section, not reordering the code.  I.e. if you have:
>> 
>>     .text
>>     ...
>>     addiu $4,$4,%lo(foo)
>>     ...
>>     lui $4,%hi(foo)
>> 
>> the assembler is expected to output the R_MIPS_HI16 .rel.text entry
>> for the lui before the R_MIPS_LO16 entry for the addiu.
>
> If you have something like that:
>
> 	.text
> 	...
> loop_label:
> 	lui $4, %hi(foo)
> 	addiu $4, $4, %lo(foo)
> 	...
> 	jmp loop_label
> 	...
>
> the compiler might be smart and change it into:
>
> 	.text
> 	...
> 	lui $4, %hi(foo)
> loop_label:
> 	addiu $4, $4, %lo(foo)
> 	...
> 	lui $4, %hi(foo)
> 	jmp loop_label
> 	...
>
> for instance, to put the lui into branch delay slot (quite a smart
> decision, this one). However now %hi and %lo are unpaired. What should the
> tool do?

It should generate:

    R_MIPS_HI16
    R_MIPS_HI16
    R_MIPS_LO16

And yes, the idea that several HI16s can be associated with the same
LO16 is also a GNU extension. ;)

(FWIW: as before, this extension, and indeed the whole idea of "out of
order" or "unpaired" %hi()s, isn't new.  It's been around for 10 years.)

Richard