Describing Mips architectures in ELF header flags

[Matt Thomas]

On Sep 17, 2013, at 12:48 PM, Jack Carter <Jack.Carter@imgtec.com> wrote:

> I have been bemoaning some use of the ELF header flags for new architectures because of lack of real estate and would like some opinions from interested parties on the list.
> 
> My contention is that we have an EI_CLASS field that is stating that this object is either 32 bit or 64 bit. Thus we don't need to have multiple EF_MIPS_ARCH_ flags such as:
> 
> EF_MIPS_ARCH_32
> EF_MIPS_ARCH_64
> EF_MIPS_ARCH_32R2
> EF_MIPS_ARCH_64R2

That's untrue.   MIPS32/MIPS64 is very different from R3000 or MIPS.
Note only that, you can have O32 binaries compiled for MIPS64.

> We should have had only EF_MIPS_ARCH_R1, and EF_MIPS_ARCH_R2 and have let the EI_CLASS take care of the rest just as we do for EFMIPS_ARCH[1-4].  In odd cases where a 32 bit object contains the 64 bit ISA  we have the EF_MIPS_32BITMODE.

anyways, it's too late.  code already exists that depends on them and 
you can't just break that.

> I understand that the cows have left the barn on the above, but going forward would like to let the EI_CLASS field handle the 32/64 bit difference.
> 
> If you agree with that, I would propose the same for E(F)_MIPS_ABI_ as well. Did we need an O32 and O64 variant? The same for EABI32/64. We have an EF_MIPS_ABI2 that works this way, although it is in the wrong spot in the flags and is taking up a bit field instead of being in the abi enumeration field (sigh).

Again, it's too late.

> I understand that these are enumerated values and  not bit fields, but they are finite.

But then, I'd like a EF_MIPS_SOFTFLOAT (or HARDFLOAT) bit.