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]

Describing Mips architectures in ELF header flags


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:

EF_MIPS_ARCH_32
EF_MIPS_ARCH_64
EF_MIPS_ARCH_32R2
EF_MIPS_ARCH_64R2

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.

Thanks,

Jack


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