[Top] [All Lists]

Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

To: Ralf Baechle <>
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
From: "Maciej W. Rozycki" <>
Date: Tue, 24 May 2005 15:50:16 +0100 (BST)
Cc: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>, Richard Sandiford <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
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.


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