Describing Mips architectures in ELF header flags

[Richard Sandiford]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Tue, 17 Sep 2013, Jack Carter wrote:
>
>> 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
>
>  Please bear in mind that EI_CLASS only refers to addressing, not the 
> machine word size.  So it's perfectly fine to have an ELF32 binary that in 
> fact requires a 64-bit processor.  Some MIPS64 processors don't even 
> support 64-bit addressing (for further details please see the definition 
> of the CP0.Config.AT field and the CP0.Status.PX bit in the architecture 
> spec), they'll only ever support ELF32 binaries.
>
>> 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.
>
>  Please note that for some reason EF_MIPS_32BITMODE is only ever set for 
> the o32 ABI, so it does not really help.  Also given what I noted above I 
> disagree that an ELF32 binary containing code that requires a 64-bit ISA 
> is an odd case.
>
>> 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).
>
>  Regrettably it's not as easy as that.  Both o64 and eabi64 use ELF32 as 
> the file container format (I've never worked with these ABIs; I gather 
> they don't use 64-bit addressing and are therefore more like n32),

FWIW, plain EABI64 is like n64 with an inbuilt -msym32.  I.e. it's LP64
and uses 64-bit addressing, but the symbols can only be 32-bit.

I've no idea if anyone uses it anymore.  Even 10 years ago, when Red Hat
had customers who used it, they preferred the -mlong32 form of EABI64,
which as you say is pretty much like n32.

Thanks,
Richard