Stanislaw Skowronek <sskowron@xxxxxxxxxxxxxxxx> 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
