linux-mips
[Top] [All Lists]

Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Tue, 24 May 2005 15:50:16 +0100 (BST)
Cc: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>, Richard Sandiford <rsandifo@redhat.com>, linux-mips@linux-mips.org
In-reply-to: <20050524142245.GG4383@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.GSO.4.10.10505240857260.13676-100000@helios.et.put.poznan.pl> <Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl> <20050524142245.GG4383@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On Tue, 24 May 2005, Ralf Baechle wrote:

> >  Do they use a different load address so that you keep an "almost fully 
> > linked" relocatable (i.e. with all objects already included, but still 
> > done with "-r") and do the final link differently for each of them?  If 
> > this is the case you should be able to keep that "almost fully linked" 
> > relocatable as ELF and then just do the final link using ELF and then 
> > `objcopy' to ECOFF.  That should work for most of the cases, although I've 
> > seen problems with firmware not recognizing MIPS III ECOFF binaries 
> > expecting a MIPS I one instead.  AFAIK, `objcopy' doesn't allow you to 
> > force a different magic number upon a conversion -- this is probably the 
> > last reason `elf2ecoff' hasn't been removed from the Linux tree yet (and 
> > you can use the tool indeed if you hit this problem).
> 
> The kernel ELF binary is too complicated for objcopy to cope with.  Fixing
> objcopy to handle this case correctly turned out to be hopeless but with
> a little linker script magic it's possible to keep the kernel vmlinux file
> within what elf2ecoff can deal with.

 Well, it used to work for me the few times I tried, except from that MIPS 
III magic number problem.  But that's not a binutils' fault.

  Maciej

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