linux-mips
[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

from [Stanislaw Skowronek] [Permanent Link][Original]
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: Tue, 24 May 2005 08:39:14 +0200 (MET DST)
Cc: linux-mips@linux-mips.org
In-reply-to: <87ekbx872j.fsf@firetop.home>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org 
> It should generate:
> 
>     R_MIPS_HI16
>     R_MIPS_HI16
>     R_MIPS_LO16
> 
> And yes, the idea that several HI16s can be associated with the same
> LO16 is also a GNU extension. ;)

Good, no problem - thanks for confirming my darkest suspicions. How can I
detect this? (I've got to emit SGI-compliant ECOFF.) I can emit sham
relocs into .rel.text that point into specially added synthetic
instructions.

Stanislaw
[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5, Richard Sandiford
Next by Date:  Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5, Richard Sandiford
Previous by Thread:  Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5, Richard Sandiford
Next by Thread:  Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5, Richard Sandiford
Indexes:  [Date] [Thread] [Top] [All Lists]