This is the mail archive of the
mailing list for the binutils project.
Re: Describing Mips architectures in ELF header flags
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Jack Carter <Jack dot Carter at imgtec dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 18 Sep 2013 13:41:52 +0100
- Subject: Re: Describing Mips architectures in ELF header flags
- Authentication-results: sourceware.org; auth=none
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE01AB545E at BADAG02 dot ba dot imgtec dot org>
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:
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
> 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
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.