linux-mips
[Top] [All Lists]

Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

To: Richard Sandiford <rsandifo@redhat.com>
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Date: Mon, 23 May 2005 18:19:42 +0200 (MET DST)
Cc: linux-mips@linux-mips.org
In-reply-to: <87oeb26vjb.fsf@firetop.home>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
> 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...

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

The user who sent the b0rked binary (`K) uses 2.15.94 or so (I'll ask him
again) / "gcc 3.5". On 2.15 / gcc 3.4.3 there is no problem like this (at
least I can't trigger it).

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

Thanks for answering,

Stanislaw




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