Re: PATCH: Fix mixing MIPS object files.

[Richard Sandiford <rsandifo at redhat dot com>]

"H. J. Lu" <hjl@lucon.org> writes:
> > > Your binutils change doesn't work with my current MIPS toolchain in
> > > my RedHat 8.x mips port. I have no plan to jump to gcc 3.3 before Red
> > > Hat does :-). Do you have a gcc patch for gcc 3.2?
> > 
> > OK, let's step back a bit ;)
> > 
> > Where did that -march=mips64 thing come from?  Yes, 3.3 supports it,
> > but I'm not quite sure what it has to do with the patch I posted.
> > 
> > When you say that the binutils change breaks you RH8.0 port, are
> > you talking about the one I just posted?  If so, could you explain
> > what goes wrong?  I'll try to fix it.
> 
> I may have missed something here. I thought the goal of your binutils
> change was to allow me to do
> 
> # /export/tools-3.2-redhat-8/bin/mipsel-linux-gcc -march=mips64 f.c -c  
> 
> That is to generate MIPS64 ISA insn which is compatible with the 32BI
> ABI.

Sort of.  It should already be possible to create mips64 o32
binaries using CVS gas and link them together using CVS ld.
That change happened a while back.

I'm not sure how easy it is to get gcc 3.2 to generate mips64
o32 code, but if it can, then I'd have expected the binutils
side to work with it.  Bug reports to the contrary are welcome ;).

The change I posted today allowed you to link mips64 o32 code
with mips2 o32 code, for instance.

Before today's patch, we merged the ARCH and MACH fields as though
they were separate, and only allowed code for 32-bit ISAs to be
linked with code for other 32-bit ISAs.  The two main changes
in the patch were:

- Merge based on the bfd_mach of ibfd and obfd.

- Take EF_MIPS_32BITMODE and EF_MIPS_ABI into account when
  testing for 32-bit/64-bit collisions.

Richard