Describing Mips architectures in ELF header flags

[Jack Carter]

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

[Matt Thomas]

Post by Jack Carter
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.
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.

Post by Jack Carter
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.

Post by Jack Carter
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.

Post by Jack Carter
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.

[Jack Carter]

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 [***@3am-software.com]
Sent: Tuesday, September 17, 2013 3:09 PM
To: Jack Carter
Cc: ***@sourceware.org
Subject: Re: Describing Mips architectures in ELF header flags

Post by Matt Thomas

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

Post by Matt Thomas

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.

Post by Matt Thomas

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.

Post by Matt Thomas

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.

[Richard Sandiford]

Post by Jack Carter
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
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.

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.

Post by Jack Carter
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.

Thanks,
Richard

[Maciej W. Rozycki]

Post by Jack Carter
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
EF_MIPS_ARCH_32
EF_MIPS_ARCH_64
EF_MIPS_ARCH_32R2
EF_MIPS_ARCH_64R2

Please bear in mind that EI_CLASS only refers to addressing, not the
machine word size. So it's perfectly fine to have an ELF32 binary that in
fact requires a 64-bit processor. Some MIPS64 processors don't even
support 64-bit addressing (for further details please see the definition
of the CP0.Config.AT field and the CP0.Status.PX bit in the architecture
spec), they'll only ever support ELF32 binaries.

Post by Jack Carter
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.

Please note that for some reason EF_MIPS_32BITMODE is only ever set for
the o32 ABI, so it does not really help. Also given what I noted above I
disagree that an ELF32 binary containing code that requires a 64-bit ISA
is an odd case.

Post by Jack Carter
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).

Regrettably it's not as easy as that. Both o64 and eabi64 use ELF32 as
the file container format (I've never worked with these ABIs; I gather
they don't use 64-bit addressing and are therefore more like n32), only
SGI-flavour n64 uses ELF64. I agree the choice made with ABI2 has been a
bit unfortunate, but that's how SGI decided to tell o32 and n32 apart and
I can understand how they didn't anticipate the proliferation of ABIs
beyond the three (o32/n64/n32) they created themselves. EF_MIPS_ABI was
only added as a GNU extension (I have no idea why the encoding of
E_MIPS_ABI_O32 was chosen as non-zero there, traditional SVR4 o32 binaries
are supposed to hold zero there; consequently we only use this setting
conditionally).

Besides, you need to retain compatibility with the preexisting tools and
environments out there, so any definitions made so far need to be
retained. We're free to be creative with any new ones though, of course.

Maciej

[Richard Sandiford]

Post by Maciej W. Rozycki

Post by Jack Carter
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
EF_MIPS_ARCH_32
EF_MIPS_ARCH_64
EF_MIPS_ARCH_32R2
EF_MIPS_ARCH_64R2

Please bear in mind that EI_CLASS only refers to addressing, not the
machine word size. So it's perfectly fine to have an ELF32 binary that in
fact requires a 64-bit processor. Some MIPS64 processors don't even
support 64-bit addressing (for further details please see the definition
of the CP0.Config.AT field and the CP0.Status.PX bit in the architecture
spec), they'll only ever support ELF32 binaries.

Post by Jack Carter
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.

Please note that for some reason EF_MIPS_32BITMODE is only ever set for
the o32 ABI, so it does not really help. Also given what I noted above I
disagree that an ELF32 binary containing code that requires a 64-bit ISA
is an odd case.

Post by Jack Carter
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).

Regrettably it's not as easy as that. Both o64 and eabi64 use ELF32 as
the file container format (I've never worked with these ABIs; I gather
they don't use 64-bit addressing and are therefore more like n32),

FWIW, plain EABI64 is like n64 with an inbuilt -msym32. I.e. it's LP64
and uses 64-bit addressing, but the symbols can only be 32-bit.

I've no idea if anyone uses it anymore. Even 10 years ago, when Red Hat
had customers who used it, they preferred the -mlong32 form of EABI64,
which as you say is pretty much like n32.

Thanks,
Richard