Re: PATCH: Fix mixing MIPS object files.

[Richard Sandiford <rsandifo at redhat dot com>]

"H. J. Lu" <hjl@lucon.org> writes:
> How about this patch?

Yes, assuming we are going to treat the 'arch' and 'mach' as
orthogonal, it looks like it does what I was after.  More below.

We'll still have the same problem with write-out as we have now.
The proposed change to _bfd_elf_final_write_processing is:

     case bfd_mach_mips3900:
-      val = E_MIPS_ARCH_1 | E_MIPS_MACH_3900;
+      isa = E_MIPS_ARCH_1;
+      cpu = E_MIPS_MACH_3900;
       break;

[snip]

 
-  elf_elfheader (abfd)->e_flags &= ~(EF_MIPS_ARCH | EF_MIPS_MACH);
-  elf_elfheader (abfd)->e_flags |= val;
+  if (((elf_elfheader (abfd)->e_flags & EF_MIPS_ARCH) != isa) && (isa != 0))
+    {
+      elf_elfheader (abfd)->e_flags &= ~EF_MIPS_ARCH;
+      elf_elfheader (abfd)->e_flags |= isa;
+    }
+
+  if (cpu != 0)
+    {
+      elf_elfheader (abfd)->e_flags &= ~EF_MIPS_MACH;
+      elf_elfheader (abfd)->e_flags |= cpu;
+    }

The problem, both before and after the above, is that we set
EF_MIPS_MACH based on obfd's bfd_mach.   That bfd_mach isn't
changed by _bfd_mips_elf_merge_private_bfd_data.

The patch I suggested was to copy the bfd mach from an input bfd
whenever we copy its EF_MIPS_MACH field.  But, after this thread,
I'm not sure that's right either.

It just strikes me that we're going into great contortions
to pretend that the ISA level and machine are separate things.
I don't see what we gain by that.

Or, starting from the beginning...

There seems to be two ways of interpreting the EF_MIPS_MACH
and EF_MIPS_ARCH bits:

1. They are almost orthogonal.  If EF_MIPS_ARCH = X and
   EF_MIPS_MACH = Y, then the binary uses two sets of
   instructions:

   - those which are defined by ISA X
   - those which are defined by the ISA for processor Y,
     but not by the "standard" ISA on which it based.

   In other words, EF_MIPS_MACH acts as a sort of ASE enumeration.

2. If EF_MIPS_MACH is a non-zero X, the code is written for
   processor X, and can use any instruction that X understands,
   subject to the other header flags (32-bit binaries can only
   use 32-bit instructions, etc.).  EF_MIPS_ARCH (redundantly)
   specifies the core ISA on which X is based.

   Otherwise, the code only uses instructions from the generic ISA
   defined by EF_MIPS_ARCH.

Reasons why I prefer (2) over (1):

- If we accept (1), we presumably have to accept the idea of
  MIPS I SB-1 code, MIPS II SB-1 code, MIPS III SB-1 code,
  etc.  I guess a MIPS III SB-1 binary could use the SB-1
  multimedia extensions, but not conditional moves.
  It could get really complicated ;)

- It copes neatly with the situations where a processor doesn't
  have certain instructions.  E.g. when a processor is based
  on MIPS II or higher, but doesn't have LL or SC.  Or when
  a processor only has a single-precision FPU.

- The main reason for varying EF_MIPS_ARCH for a given EF_MIPS_MACH
  seems to be to say that a binary contains 32-bit code.  There are
  other flags for that.

Richard