This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: Describing Mips architectures in ELF header flags
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: Matt Thomas <matt at 3am-software dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 17 Sep 2013 23:08:21 +0000
- 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>,<9B89FD3F-AAEC-46A7-9F44-6152422FA554 at 3am-software dot com>
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.