[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: "Maciej W. Rozycki" <>
Date: Tue, 24 May 2005 11:40:53 +0100 (BST)
Cc: Richard Sandiford <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <>
On Tue, 24 May 2005, Stanislaw Skowronek wrote:

> > Sorry if this is a dumb question, but why do you need to generate
> > _relocatable_ ECOFF?
> It allows me to boot all Indys and O2s off the same binary. Nice for boot
> CDs. Especially that Octanes and Origins should be bootable from another
> one... just like IRIX.

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

 Trying to support GNU extensions in ECOFF is probably hopeless and not 
worth the hassle and the file format is likely to be obsoleted by the 
toolchain soon (if not already done), except from BFD -- which'll let you 
continue doing `objcopy', `objdump', etc.


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