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:
> It seems that gcc (with -O; -O0 fixes the issue) will generate R_MIPS_HI16
> without succeeding R_MIPS_LO16 (or the other way - but it's not a real
> problem that way) in '.rel.text' (not '.rela.text'). According to SGI ELF
> spec this combination is invalid (well, addend AHL is created from low 16
> bits from HI16 and low 16 bits from LO16, and the actual result of
> relocation might depend on the LO16 part - at least this is what I
> understood from the specific[a]tion); it also upsets Indy PROM when
> converted into ECOFF.
>
> Gcc 3.4.3 does not exhibit this (wanton) behavior. What the heck?

Remember that support for %hi() and %lo() on REL targets is a GNU extension.
The assembler is expected to reorder the relocations so that the HI16s
come before the LO16s.  It sounds like this isn't happening in your case,
so which version of binutils are you using?

This isn't really a change from gcc 3.4 to "gcc 3.5" (now known as 4.0 ;).
It has long been possible for gcc's assembly code to contain "out of order"
%hi()s and %lo()s.  On the other hand, the more aggressive the optimisers
are, the more likely you are to see it, so the behaviour will certainly
be different in specific testcases.

Richard