Stanislaw Skowronek <sskowron@xxxxxxxxxxxxxxxx> writes:
>> Remember that support for %hi() and %lo() on REL targets is a GNU extension.
>
> Erm. Are you sure?
>
> SGI's ELF64 spec says:
>
> "Any of the relocation types may appear in either a SHT_REL or a SHT_RELA
> relocation section, except that relocation types involving AHL operands
> are forbidden in a 64-bit SHT_REL section and discouraged in a 32-bit
> SHT_REL section."
>
> There is no word of GNU there and in any case SGI had their own tools. But
> again, it is possible that the idea bounced back and forth...
I'm talking about the %hi() and %lo() relocation _operators_,
not the ELF relocations themselves. The ELF spec has nothing
to say about the syntax of assembler relocation operators.
>> This isn't really a change from gcc 3.4 to "gcc 3.5" (now known as 4.0 ;).
>
> Well, one of %hi()s is reordered to beginning of a loop and this is what
> makes it unpaired. I don't think that any assembler could fix that.
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.
Richard
