This is the mail archive of the 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]

Re: Describing Mips architectures in ELF header flags

Jack Carter <> writes:
> 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.

EI_CLASS itself isn't enough, because it only gives the ELF size,
not the architecture size.  Of the four(!) 64-bit ABIs, only n64 uses
ELFCLASS64.  o64, n32 and EABI64 all use ELFCLASS32.

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

Well, I can't help thinking that flags are the least of our worries as
far as new ABIs go. :-)  We already have 6 main ABIs (o32, o64, n32, n64,
EABI32 and EABI64) as well as variants like EABI64 -mlong32.  I think
there'd need to be a very strong justification for adding yet more.
Even if we did, I'd hope it would be at most 2 (one for 32-bit, one for
64-bit), and there's plenty of room in the low 3 bits of the existing
ABI field for that.

As far as the architecture goes: I suppose we could require logic
to work out the architecture by taking the ABI into account.
We have enough room in the existing architecture field for 7 more values.
Under the current scheme, that would give us 3 more revisions while leaving
a final value that could be used as an escape.  Going for the
ABI-dependent approach would give us 6 more revisions with an escape
or 7 without it.  It isn't totally infeasible that there'd be 7 more
revisions though.

So TBH I think changing tack now is only putting off the inevitable.
It also means that once we have the program-header escape, we'll then
have three ways of working out the architecture: the current scheme
where the architecture field is stand-alone, the proposed scheme
where the architecture field depends on the ABI, and then the
program-header-based scheme.  I'd think it'd better just to have
the first and the last.

Also, it should always be the case under the current scheme that a
64-bit "MACH" has a 64-bit "ARCH".  I'd prefer we kept it that way if
possible, although it's a much more minor reason than the one above.

I assume we won't need architecture flags for r4, just r3, r5 and
whatever the future holds.  Is that right?  If so, the current scheme
will only run out after r6.  With the rate that we're eating up flags
for features other than the architecture, I think we'll need to have
the escape discussed in the other thread before then anyway.  So FWIW,
my vote would be for us to continue with the current scheme until r6 and
(concurrently) define something better than ELF flags for when we run out.
The new scheme should give us as many architecture bits as we need.


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