This is the mail archive of the
mailing list for the binutils project.
Re: Describing Mips architectures in ELF header flags
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Jack Carter <Jack dot Carter at imgtec dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 18 Sep 2013 14:46:02 +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> <alpine dot DEB dot 1 dot 10 dot 1309180014530 dot 4379 at tp dot orcam dot me dot uk>
"Maciej W. Rozycki" <email@example.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:
> 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),
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.