This is the mail archive of the
mailing list for the binutils project.
Describing Mips architectures in ELF header flags
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 17 Sep 2013 19:48:50 +0000
- Subject: Describing Mips architectures in ELF header flags
- Authentication-results: sourceware.org; auth=none
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:
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.
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).
I understand that these are enumerated values and not bit fields, but they are finite.