Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

[Ralf Baechle <ralf@linux-mips.org>]

On Tue, May 24, 2005 at 11:40:53AM +0100, Maciej W. Rozycki 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.

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

If anything a real ECOFF toolchain would be needed.  Teaching ECOFF about
all the ELF magic like complex handling of certain magic symbols etc. is
a waste of time ...

  Ralf