linux-mips
[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 <rsandifo@redhat.com>
Date: Tue, 24 May 2005 07:56:35 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <Pine.GSO.4.10.10505240837530.12717-100000@helios.et.put.poznan.pl> (Stanislaw Skowronek's message of "Tue, 24 May 2005 08:39:14 +0200 (MET DST)")
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.GSO.4.10.10505240837530.12717-100000@helios.et.put.poznan.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL> writes:

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

Sorry if this is a dumb question, but why do you need to generate
_relocatable_ ECOFF?  If you really need to do that, I think you'll
just have to force gcc to use assembler macros, ala:

   gcc -mno-explicit-relocs -mno-split-addresses

Richard

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