Home Original page

Describing Mips architectures in ELF header flags

Jack Carter Jack.Carter@imgtec.com
Tue Sep 17 23:09:00 GMT 2013 
I must not have been clear. I am talking about future revs of the abi and arch. The existing values are here to stay.

_______________________________________
From: Matt Thomas [matt@3am-software.com]
Sent: Tuesday, September 17, 2013 3:09 PM
To: Jack Carter
Cc: binutils@sourceware.org
Subject: Re: Describing Mips architectures in ELF header flags

On Sep 17, 2013, at 12:48 PM, Jack Carter <Jack.Carter@imgtec.com> wrote:

> > 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

> That's untrue.   MIPS32/MIPS64 is very different from R3000 or MIPS.
> Note only that, you can have O32 binaries compiled for MIPS64.

Does that make sense? Do we want to use up future enumerations for this? If this is a fringe use the flag belongs in the NOTE segment.   

> > 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.

> anyways, it's too late.  code already exists that depends on them and
> you can't just break that.

Not talking about changing current flags just using them as examples.

> > 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).

> Again, it's too late.

Not talking about changing current flags.

> > I understand that these are enumerated values and  not bit fields, but they are finite.

> But then, I'd like a EF_MIPS_SOFTFLOAT (or HARDFLOAT) bit.

This should be handled in the NOTE segment/section not in the ELF header.
More information about the Binutils mailing list