MIPS ECOFF ld --embedded-relocs: looks like a bug

[msokolov at ivan dot Harhan dot ORG (Michael Sokolov)]

Hi there,

I'm looking at the MIPS ECOFF ld --embedded-relocs code with an eye toward
porting it to m68k (COFF and ELF), and I see what seems to be a bug. This code
was written by Ian, so I hope he still reads this list and will comment on
this. :-) In ld/emultempl/mipsecoff.em, after having created the .rel.sdata
section to hold the embedded relocs in gld{EMULATION_NAME}_after_open, it fills
it in gld{EMULATION_NAME}_after_allocation by calling ecoff-mips BFD backend
function bfd_mips_ecoff_create_embedded_relocs for each input BFD. Here is my
question. What if an input BFD is not ecoff-mips? What if I configure and build
a mips-ecoff toolchain with a libbfd.a that has all targets in it and run
mips-ecoff-ld --embedded-relocs -o myexec myobj.o, where myobj.o is an ELF
object? From what I see, bfd_mips_ecoff_create_embedded_relocs in the ecoff-
mips backend will be called with an elf32-mips BFD. Wouldn't this core dump or
something like that?

It seems to me that one must first check the BFD target before directly calling
a backend function in this fashion. What should we do if the BFD target isn't
what we expect? I don't know MIPS, so I can't judge the intent of the
--embedded-relocs code and the fitness of the implementation for its purpose,
but the comments say that ld --embedded-relocs is legal only for objects
assembled with GNU as -membedded-pic. Looking at gas/config/tc-mips.c, I see
that GNU as appears to support -membedded-pic equally well for ECOFF and ELF.
Thus it seems to me that bfd_mips_ecoff_create_embedded_relocs should be ported
to the elf32-mips backend as well. What should we do in ld until then? Give a
"sorry, not supported yet" error message when trying to link in an ELF object?

This caught my sight because I want to port this to m68k, where I will
definitely need to support both COFF and ELF and allow linking COFF objects
into ELF executables, together with ELF objects, with an ELF toolchain (and
maybe even vice-versa, although that is not important).

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)