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:
>> 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