Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Stanislaw




[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux