This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Describing Mips architectures in ELF header flags


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), only 
SGI-flavour n64 uses ELF64.  I agree the choice made with ABI2 has been a 
bit unfortunate, but that's how SGI decided to tell o32 and n32 apart and 
I can understand how they didn't anticipate the proliferation of ABIs 
beyond the three (o32/n64/n32) they created themselves.  EF_MIPS_ABI was 
only added as a GNU extension (I have no idea why the encoding of 
E_MIPS_ABI_O32 was chosen as non-zero there, traditional SVR4 o32 binaries 
are supposed to hold zero there; consequently we only use this setting 
conditionally).

 Besides, you need to retain compatibility with the preexisting tools and 
environments out there, so any definitions made so far need to be 
retained.  We're free to be creative with any new ones though, of course.

  Maciej


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]