[Top] [All Lists]

Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

To: "Maciej W. Rozycki" <>
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 12:47:26 +0200 (MET DST)
Cc: Richard Sandiford <>,
In-reply-to: <>
Original-recipient: rfc822;
> > 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?

Yes, exactly.

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

I tried objcopy (it was my first thought), for one reason or another it
didn't work (internal BFD error something). Reportedly ECOFF is belly-up
in current GNU binutils - at least it is what I heard.

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

My input is elf32-tradbigmips. So I entirely don't care for binutils'
ECOFF anymore, and I consider this a good thing. As I said, objcopy didn't
work at all. Fixing BFD is not my job (it's a monster of Frankensteinian
proportions), I think that it is actually much easier to write my own
converter (well, I did it, and it works - except that funny HI/LO mismatch
I'm going to work around).


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