[Top] [All Lists]

Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
From: Richard Sandiford <>
Date: Mon, 23 May 2005 18:23:17 +0100
In-reply-to: <> (Stanislaw Skowronek's message of "Mon, 23 May 2005 18:19:42 +0200 (MET DST)")
Original-recipient: rfc822;
References: <87oeb26vjb.fsf@firetop.home> <>
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
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 section, not reordering the code.  I.e. if you have:

    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.


<Prev in Thread] Current Thread [Next in Thread>