PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

[H. J. Lu]

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

I'd like to fix binutils ASAP. Here is a patch.


On Thu, Jul 25, 2002 at 03:29:12PM +0200, Carsten Langgaard wrote:
> "Maciej W. Rozycki" wrote:
> 
> > On Wed, 24 Jul 2002, Carsten Langgaard wrote:
> >
> > > We at MIPS are in the process of making an ABI spec for all this, which
> > > is the intention that should be used by the tool-vendors.  So please
> > > don't change the ELF header defines.
> >
> >  It'd be better the spec matched the real world...
> 
> Shouldn't it be the other way around, the real world should follow the spec
> ;-)
> The whole ELF header definition is just one big mess, because we are lacking
> a proper ABI spec.
> That's what has motivated us, to begin making this ABI spec.
> 
> We have defined the e_flags this way:
> 
> /* ELF header e_flags defines. MIPS architecture level. */
> #define EF_MIPS_ARCH_1      0x00000000  /* -mips1 code.  */
> #define EF_MIPS_ARCH_2      0x10000000  /* -mips2 code.  */
> #define EF_MIPS_ARCH_3      0x20000000  /* -mips3 code.  */
> #define EF_MIPS_ARCH_4      0x30000000  /* -mips4 code.  */
> #define EF_MIPS_ARCH_5      0x40000000  /* -mips5 code.  */
> #define EF_MIPS_ARCH_32     0x60000000  /* MIPS32 code.  */
> #define EF_MIPS_ARCH_64     0x70000000  /* MIPS64 code.  */
> #define EF_MIPS_ARCH_32R2   0x80000000  /* MIPS32 code.  */
> #define EF_MIPS_ARCH_64R2   0x90000000  /* MIPS64 code.  */
> 
> The missing value 0x50000000, is because IRIX has defined a EF_MIPS_ARCH_6
> and Algorithmics has a E_MIPS_ARCH_ALGOR_32, which has this value.
> If you look at the elf.h file in glibc, the you will see, it has the same
> values as the kernel.
> 
> So I would prefer we fix that in binutils, I guess it not a problem as long
> as you don't have a toolchain that can generate MIPS32 or MIPS64 code.
> 
> 
> >
> > > I don't see that is wrong with checking the ISA level, I rather have an
> > > error telling me that I can't execute a certain ISA level than
> > > eventually getting a reserved instruction or something worse like
> > > something unpredictable.
> >
> >  Well, -ENOEXEC in not any more useful than SIGILL -- with the latter you
> > have at least an idea what happened.  The ISA check is not implemented for
> > any Linux port, so there no suitable hook in binfmt_*.c files.  You might
> > propose an implementation if that's particularly important for you.
> >
> 
> I would like a message telling me that I can't run this ISA level on the
> system.
> Imagined what would happen, if you execute mips3 code and execute ld/sd
> instructions on a mips32 kernel (but on a 64-bit processor), the kernel only
> save half the register and then everything could happen.
> 
> 
> >
> > > You are obviously right about the elf_check_arch in the 64-bit part of
> > > the kernel is broken.  It's probably just be copied from the 32-bit part
> > > without changes, like a lot of the code in the 64-bit kernel is.
> >
> >  Possibly, but it still makes me wonder why it wasn't adjusted at the time
> > binfmt_elf32.c was created...
> >
> >   Maciej
> >
> > --
> > +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> > +--------------------------------------------------------------+
> > +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 
> --
> _    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
> |\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
> | \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
>   TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
>                    Denmark             http://www.mips.com
> 
> 
> 

[-- Attachment #2: elf-mips.patch --]
[-- Type: text/plain, Size: 1023 bytes --]

2002-07-25  H.J. Lu <hjl@gnu.org>

	* mips.h (E_MIPS_ARCH_6): New.
	(E_MIPS_ARCH_ALGOR_32): New.
	(E_MIPS_ARCH_32): Changed.
	(E_MIPS_ARCH_64): Changed.
	(E_MIPS_ARCH_32R2): New.
	(E_MIPS_ARCH_64R2): New.

--- include/elf/mips.h.mips	Fri Sep  7 15:43:58 2001
+++ include/elf/mips.h	Thu Jul 25 08:21:10 2002
@@ -139,11 +139,23 @@ END_RELOC_NUMBERS (R_MIPS_maxext)
 /* -mips5 code.  */
 #define E_MIPS_ARCH_5           0x40000000
 
+/* Used by IRIX.  */
+#define E_MIPS_ARCH_6           0x50000000
+
+/* Used by Algorithmics.  */
+#define E_MIPS_ARCH_ALGOR_32    0x50000000
+
 /* -mips32 code.  */
-#define E_MIPS_ARCH_32          0x50000000
+#define E_MIPS_ARCH_32          0x60000000
 
 /* -mips64 code.  */
-#define E_MIPS_ARCH_64          0x60000000
+#define E_MIPS_ARCH_64          0x70000000
+
+/* MIPS32 code.  */
+#define E_MIPS_ARCH_32R2        0x80000000
+
+/* MIPS64 code.  */
+#define E_MIPS_ARCH_64R2        0x90000000
 
 /* The ABI of the file.  Also see EF_MIPS_ABI2 above. */
 #define EF_MIPS_ABI		0x0000F000

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

[cgd]

[ Added David Anderson (hopefully still 8-) @ SGI to the CC list,
since he's been helpful with sorting out questions like this in the
past.

At Thu, 25 Jul 2002 15:26:19 +0000 (UTC), "H. J. Lu" wrote:

> I'd like to fix binutils ASAP. Here is a patch.

People using stock binutils have been using the current binutils MIPS
arch values for a While now.  They were in 2.11.1 and later binutils
releases, as well.


> > /* ELF header e_flags defines. MIPS architecture level. */
> > #define EF_MIPS_ARCH_1      0x00000000  /* -mips1 code.  */
> > #define EF_MIPS_ARCH_2      0x10000000  /* -mips2 code.  */
> > #define EF_MIPS_ARCH_3      0x20000000  /* -mips3 code.  */
> > #define EF_MIPS_ARCH_4      0x30000000  /* -mips4 code.  */
> > #define EF_MIPS_ARCH_5      0x40000000  /* -mips5 code.  */
> > #define EF_MIPS_ARCH_32     0x60000000  /* MIPS32 code.  */
> > #define EF_MIPS_ARCH_64     0x70000000  /* MIPS64 code.  */
> > #define EF_MIPS_ARCH_32R2   0x80000000  /* MIPS32 code.  */
> > #define EF_MIPS_ARCH_64R2   0x90000000  /* MIPS64 code.  */

Why are 2 definitions of MIPS32 and MIPS64 needed?

Certainly, if you do need different definitions, they need much better
comments than that.


> > The missing value 0x50000000, is because IRIX has defined a EF_MIPS_ARCH_6
> > and Algorithmics has a E_MIPS_ARCH_ALGOR_32, which has this value.

It's unfortunate that MIPS is only at this late stage getting into the
business of defining these fields.

Has IRIX actually _used_ EF_MIPS_ARCH_6 for anything (shipped)?  That
i'm a bit concerned about, since interoperability with IRIX would be a
good thing given that SGI has been setting the only ABI example to
follow for MIPS.

Algorithmics may have done something different, but they have also
been capable of contributing their binutils-related changes back to
the binutils projects, yet they have not.  Why muck things up for
people who _have_, or who've been using the tools, on their account?




cgd
-- 
Chris Demetriou                                            Broadcom Corporation
Senior Staff Design Engineer                  Broadband Processor Business Unit
  Any opinions expressed in this message are mine, not necessarily Broadcom's.

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

[David Anderson]

Chris Demetriou  cgd@broadcom.com writes:
>[ Added David Anderson (hopefully still 8-) @ SGI to the CC list,
>since he's been helpful with sorting out questions like this in the
>past.
>
>At Thu, 25 Jul 2002 15:26:19 +0000 (UTC), "H. J. Lu" wrote:
>
>> I'd like to fix binutils ASAP. Here is a patch.
>
>People using stock binutils have been using the current binutils MIPS
>arch values for a While now.  They were in 2.11.1 and later binutils
>releases, as well.
>
>
>> > /* ELF header e_flags defines. MIPS architecture level. */
>> > #define EF_MIPS_ARCH_1      0x00000000  /* -mips1 code.  */
>> > #define EF_MIPS_ARCH_2      0x10000000  /* -mips2 code.  */
>> > #define EF_MIPS_ARCH_3      0x20000000  /* -mips3 code.  */
>> > #define EF_MIPS_ARCH_4      0x30000000  /* -mips4 code.  */
>> > #define EF_MIPS_ARCH_5      0x40000000  /* -mips5 code.  */
>> > #define EF_MIPS_ARCH_32     0x60000000  /* MIPS32 code.  */
>> > #define EF_MIPS_ARCH_64     0x70000000  /* MIPS64 code.  */
>> > #define EF_MIPS_ARCH_32R2   0x80000000  /* MIPS32 code.  */
>> > #define EF_MIPS_ARCH_64R2   0x90000000  /* MIPS64 code.  */
>
>Why are 2 definitions of MIPS32 and MIPS64 needed?
>
>Certainly, if you do need different definitions, they need much better
>comments than that.
>
>
>> > The missing value 0x50000000, is because IRIX has defined a EF_MIPS_ARCH_6
>> > and Algorithmics has a E_MIPS_ARCH_ALGOR_32, which has this value.

The latest IRIX def (not yet released header fragment):

elf.h:#define EF_MIPS_ARCH              0xf0000000      /* mask: 4 bit field */
elf.h:#define EF_MIPS_ARCH_1            0x00000000      /* MIPS I ISA */
elf.h:#define EF_MIPS_ARCH_2            0x10000000      /* MIPS II ISA */
elf.h:#define EF_MIPS_ARCH_3            0x20000000      /* MIPS III ISA */
elf.h:#define EF_MIPS_ARCH_4            0x30000000      /* MIPS IV ISA */
elf.h:#define EF_MIPS_ARCH_5            0x40000000      /* MIPS V ISA */
elf.h:#define EF_MIPS_ARCH_6            0x50000000
elf.h:#define EF_MIPS_ARCH_32           0x50000000      /* MIPS32 ISA */
elf.h:#define EF_MIPS_ARCH_64           0x60000000      /* MIPS64 ISA */

EF_MIPS_ARCH_32 duplicates EF_MIPS_ARCH_6 for basically historical
reasons I think : we did not want some compile to fail for no good reason
if EF_MIPS_ARCH_6 was referred to.
We never have used EF_MIPS_ARCH_6 for anything.

The EF_MIPS_ARCH_64 0x60000000
we got from binutils(!) around Nov 2001, according to my
email records.  Without much certainty it was the right value.

>It's unfortunate that MIPS is only at this late stage getting into the
>business of defining these fields.
>
>Has IRIX actually _used_ EF_MIPS_ARCH_6 for anything (shipped)?  That
>i'm a bit concerned about, since interoperability with IRIX would be a
>good thing given that SGI has been setting the only ABI example to
>follow for MIPS.

No, IRIX never used EF_MIPS_ARCH_6            0x50000000 for anything 
shipped.

>Algorithmics may have done something different, but they have also
>been capable of contributing their binutils-related changes back to
>the binutils projects, yet they have not.  Why muck things up for
>people who _have_, or who've been using the tools, on their account?

Nor have we shipped EF_MIPS_ARCH_32 or EF_MIPS_ARCH_64 
(from the IRIX set above).

While I cannot speak for everyone here, I'm pretty sure that
we can follow what is eventually adopted, since the values in question
represent nothing shipped.

We added EF_MIPS_ARCH_5            0x40000000 
and EF_MIPS_ARCH_6            0x50000000 to elf.h 
long long ago. 

I don't *think* we've shipped EF_MIPS_ARCH_5            0x40000000
either, but I could well be wrong on that, I forget
what was said/done on EF_MIPS_ARCH_5.  If it matters
I could check (let me know).

I've added a couple key interested sgi folks (via bcc,
I don't know they want email addresses exposed) to this
response.  So if I've made mistakes above such can
get corrrected.


Regards,
David B. Anderson davea@sgi.com http://reality.sgiweb.org/davea

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

[cgd]

At Thu, 25 Jul 2002 15:26:19 +0000 (UTC), "H. J. Lu" wrote:
> I'd like to fix binutils ASAP. Here is a patch.

OK, so, I've seen no response so far that indicates that binutils
should actually be changed.


to recap:

* Binutils has deployed these values in several releases now, and I
  know for a fact that people are using binaries with these values.

* SGI has followed binutils' lead in selecting values.

* Algorithmics did something else, though it's not clear what the
  difference between "ARCH_ALGOR_32" and "ARCH_32" really is.


It seems obvious that the simplest solution that causes the least pain
all around is to go with the numbering binutils currently uses.  This
will probably cause a little bit of pain for Algorithmics, but, well,
they could have sent something to binutils to indicate use of that
number, and i'm quite sure that most of the rest of us have had to put
temporary backward-compat hacks in our own codebases for incompatible
changes made by others in the past.  It's not that hard and doesn't
cause long-term pain.


I could understand that MIPS or Algorithmics might like that, but I
think there're a bunch of morals to this story: if you want to lead on
ABI issues, get out in front of them (you can't lead from the back
8-); interact with the tool development and use communities about such
issues _before_ solutions are needed and agreed upon in those
communities; and, you're hacking open source code like binutils,
contribute your changes back as soon as you possibly can.

I'd also like to point out that saying "mips will be defining this
ABI, so you should all change your code to work with it" without,
AFAIK, even providing a draft of said ABI... is unlikely to produce
positive results even _if_ there's no precedent that would go against
the requested change.  (if somebody has a ptr, i'd be glad to be
corrected 8-)

(I wonder what other incompatibilities may exist between this new ABI
and the current binutils MIPS ELF headers...)



cgd
-- 
Chris Demetriou                                            Broadcom Corporation
Senior Staff Design Engineer                  Broadband Processor Business Unit
  Any opinions expressed in this message are mine, not necessarily Broadcom's.

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

[Paul Koning]

>>>>> "cgd" == cgd  <cgd@broadcom.com> writes:

 cgd> At Thu, 25 Jul 2002 15:26:19 +0000 (UTC), "H. J. Lu" wrote:
 >> I'd like to fix binutils ASAP. Here is a patch.

 cgd> OK, so, I've seen no response so far that indicates that
 cgd> binutils should actually be changed.

Agreed, for all the reasons you so clearly stated.

	paul

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC:elf_check_arch() rework)

[Carsten Langgaard]

First of all I will like to thank you for all the replies, we really appreciate
it, because it helps us in our process of making a proper ABI spec.
I known it's a relative late state we are trying to provide the community with an
ABI document, but I guess it's better to be late than to never show up.
I believe we all could benefit from such a document, it's only in a internal draft
version right now, but it might be a good idea to send it out to the community for
comments, before the finally version.
But we are still in an early state and on the learning curve.

Regarding the ELF header arch values, we did try to select whose in order not to
break things for anyone.
I'm also a little surprised to see these value out in binutils, it really surprise
me, if we got a linux toolchain that can generate mips32/mips64 code.

MIPS32R2 and MIPS64R2 is a new enhanced version of MIPS32 and MIPS64 architecture,
which among other things include some new instructions.

Regarding Algorithmics, I don't know if everybody are aware of it, but we have
just acquired Algorithmics.
That among other things, is done in order to play a stronger part in the
development of the toolchain. And their work will be pushed back to the community.

Algorithmics have done a MIPS32 compiler for us, which is very close to be
released.

I hope this clarify a little bit, what our motivation are.
/Carsten


cgd@broadcom.com wrote:

> At Thu, 25 Jul 2002 15:26:19 +0000 (UTC), "H. J. Lu" wrote:
> > I'd like to fix binutils ASAP. Here is a patch.
>
> OK, so, I've seen no response so far that indicates that binutils
> should actually be changed.
>
> to recap:
>
> * Binutils has deployed these values in several releases now, and I
>   know for a fact that people are using binaries with these values.
>
> * SGI has followed binutils' lead in selecting values.
>
> * Algorithmics did something else, though it's not clear what the
>   difference between "ARCH_ALGOR_32" and "ARCH_32" really is.
>
> It seems obvious that the simplest solution that causes the least pain
> all around is to go with the numbering binutils currently uses.  This
> will probably cause a little bit of pain for Algorithmics, but, well,
> they could have sent something to binutils to indicate use of that
> number, and i'm quite sure that most of the rest of us have had to put
> temporary backward-compat hacks in our own codebases for incompatible
> changes made by others in the past.  It's not that hard and doesn't
> cause long-term pain.
>
> I could understand that MIPS or Algorithmics might like that, but I
> think there're a bunch of morals to this story: if you want to lead on
> ABI issues, get out in front of them (you can't lead from the back
> 8-); interact with the tool development and use communities about such
> issues _before_ solutions are needed and agreed upon in those
> communities; and, you're hacking open source code like binutils,
> contribute your changes back as soon as you possibly can.
>
> I'd also like to point out that saying "mips will be defining this
> ABI, so you should all change your code to work with it" without,
> AFAIK, even providing a draft of said ABI... is unlikely to produce
> positive results even _if_ there's no precedent that would go against
> the requested change.  (if somebody has a ptr, i'd be glad to be
> corrected 8-)
>
> (I wonder what other incompatibilities may exist between this new ABI
> and the current binutils MIPS ELF headers...)
>
> cgd
> --
> Chris Demetriou                                            Broadcom Corporation
> Senior Staff Design Engineer                  Broadband Processor Business Unit
>   Any opinions expressed in this message are mine, not necessarily Broadcom's.

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC:elf_check_arch() rework)

[Dan Temple]

I've now heard a bit of the history from Nigel at Algorithmics, and to summarize, they chose the 6 and 7 values for MIPS32/64 after Cygnus, who were also producing a MIPS32/64 toolchain, had chosen these. (Algor had originally used the value of 5 for MIPS32, but had to changed when both SGI (who assigned it to something else) and Cygnus chose otherwise). Hence ARCH_ALGOR_32.

A little research also reveals that the value of 5 for ARCH_32 was first checked into CVS in Dec 2000 by Nick Clifton at Redhat.

Anyway, that's why things are the way they are, but may not help much as to a resolution :(

My personal take on this is that the two main commercial providers (Cygnus and Algor) of MIPS32/64-capable GNU toolchains have been using 6 & 7 for quite a while, SGI "agree", and that this is quite a precedent. Hopefully the ABI process will soon shake any other issues out too.

/Dan

On Mon, 29 Jul 2002, Carsten Langgaard wrote:

> First of all I will like to thank you for all the replies, we really appreciate
> it, because it helps us in our process of making a proper ABI spec.
> I known it's a relative late state we are trying to provide the community with an
> ABI document, but I guess it's better to be late than to never show up.
> I believe we all could benefit from such a document, it's only in a internal draft
> version right now, but it might be a good idea to send it out to the community for
> comments, before the finally version.
> But we are still in an early state and on the learning curve.
> 
> Regarding the ELF header arch values, we did try to select whose in order not to
> break things for anyone.
> I'm also a little surprised to see these value out in binutils, it really surprise
> me, if we got a linux toolchain that can generate mips32/mips64 code.
> 
> MIPS32R2 and MIPS64R2 is a new enhanced version of MIPS32 and MIPS64 architecture,
> which among other things include some new instructions.
> 
> Regarding Algorithmics, I don't know if everybody are aware of it, but we have
> just acquired Algorithmics.
> That among other things, is done in order to play a stronger part in the
> development of the toolchain. And their work will be pushed back to the community.
> 
> Algorithmics have done a MIPS32 compiler for us, which is very close to be
> released.
> 
> I hope this clarify a little bit, what our motivation are.
> /Carsten
> 
> 
> cgd@broadcom.com wrote:
> 
> > At Thu, 25 Jul 2002 15:26:19 +0000 (UTC), "H. J. Lu" wrote:
> > > I'd like to fix binutils ASAP. Here is a patch.
> >
> > OK, so, I've seen no response so far that indicates that binutils
> > should actually be changed.
> >
> > to recap:
> >
> > * Binutils has deployed these values in several releases now, and I
> >   know for a fact that people are using binaries with these values.
> >
> > * SGI has followed binutils' lead in selecting values.
> >
> > * Algorithmics did something else, though it's not clear what the
> >   difference between "ARCH_ALGOR_32" and "ARCH_32" really is.
> >
> > It seems obvious that the simplest solution that causes the least pain
> > all around is to go with the numbering binutils currently uses.  This
> > will probably cause a little bit of pain for Algorithmics, but, well,
> > they could have sent something to binutils to indicate use of that
> > number, and i'm quite sure that most of the rest of us have had to put
> > temporary backward-compat hacks in our own codebases for incompatible
> > changes made by others in the past.  It's not that hard and doesn't
> > cause long-term pain.
> >
> > I could understand that MIPS or Algorithmics might like that, but I
> > think there're a bunch of morals to this story: if you want to lead on
> > ABI issues, get out in front of them (you can't lead from the back
> > 8-); interact with the tool development and use communities about such
> > issues _before_ solutions are needed and agreed upon in those
> > communities; and, you're hacking open source code like binutils,
> > contribute your changes back as soon as you possibly can.
> >
> > I'd also like to point out that saying "mips will be defining this
> > ABI, so you should all change your code to work with it" without,
> > AFAIK, even providing a draft of said ABI... is unlikely to produce
> > positive results even _if_ there's no precedent that would go against
> > the requested change.  (if somebody has a ptr, i'd be glad to be
> > corrected 8-)
> >
> > (I wonder what other incompatibilities may exist between this new ABI
> > and the current binutils MIPS ELF headers...)
> >
> > cgd
> > --
> > Chris Demetriou                                            Broadcom Corporation
> > Senior Staff Design Engineer                  Broadband Processor Business Unit
> >   Any opinions expressed in this message are mine, not necessarily Broadcom's.
> 
> --
> _    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
> |\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
> | \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
>   TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
>                    Denmark             http://www.mips.com
> 
> 
> 
> 

-- 
Dan Temple, Eng. Mgr.     Tel: +45-44865512     
  MIPS Denmark              Fax: +45-44865556     
  Lautrupvang 4B            mailto:dant@mips.com  
  DK-2750 Ballerup          http://www.mips.com
  Denmark                  

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC:elf_check_arch() rework)

[Maciej W. Rozycki]

On Tue, 30 Jul 2002, Dan Temple wrote:

> I've now heard a bit of the history from Nigel at Algorithmics, and to
> summarize, they chose the 6 and 7 values for MIPS32/64 after Cygnus, who
> were also producing a MIPS32/64 toolchain, had chosen these. (Algor had
> originally used the value of 5 for MIPS32, but had to changed when both
> SGI (who assigned it to something else) and Cygnus chose otherwise).
> Hence ARCH_ALGOR_32. 
> 
> A little research also reveals that the value of 5 for ARCH_32 was first
> checked into CVS in Dec 2000 by Nick Clifton at Redhat. 

 Hmm, the relevant ChangeLog entry is:

2000-10-16  Chris Demetriou  <cgd@sibyte.com>

	* mips.h (E_MIPS_ARCH_32): New constant.
	(E_MIPS_MACH_MIPS32, E_MIPS_MACH_MIPS32_4K): Replace the
	former with the latter.

	* mips.h (E_MIPS_ARCH_5, E_MIPS_ARCH_64): New definitions.

	* mips.h (E_MIPS_MACH_SB1): New constant.

Patches went in with two commits on Dec 1st and 2nd, 2000: 

http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/include/elf/mips.h.diff?r1=1.8&r2=1.9&cvsroot=src

http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/include/elf/mips.h.diff?r1=1.9&r2=1.10&cvsroot=src

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

[cgd]

At Tue, 30 Jul 2002 14:10:53 +0000 (UTC), "Dan Temple" wrote:
> I've now heard a bit of the history from Nigel at Algorithmics, and
> to summarize, they chose the 6 and 7 values for MIPS32/64 after
> Cygnus, who were also producing a MIPS32/64 toolchain, had chosen
> these. (Algor had originally used the value of 5 for MIPS32, but had
> to changed when both SGI (who assigned it to something else) and
> Cygnus chose otherwise). Hence ARCH_ALGOR_32.

Uh, i believe i've seen a snapshot of the Cygnus MIPS32/64 toolchain
you describe.  It was described to me as an "alpha" snapshot.  I have
no reason to believe it was ever released as a commercial-quality
product.

I've made an inquiry, and my understanding is that Cygnus/RedHat
internally use the same values as the public tools
(i.e. EF_MIPS_ARCH_MIPS32 == 5, ..._MIPS64 == 6).


> My personal take on this is that the two main commercial providers
> (Cygnus and Algor) of MIPS32/64-capable GNU toolchains have been
> using 6 & 7 for quite a while,

As noted above, at least for Cygnus, I believe this assertion is
not correct.


> SGI "agree",

with the current master binutils sources.  8-)

As noted in the message:

	http://sources.redhat.com/ml/binutils/2002-07/msg00681.html

SGI is using the same values as the master public GNU binutils,
i.e. MIPS32 == 5, MIPS64 == 6.  It sounds like it wouldn't hurt them
much to switch, but following your suggestion _would_ involve them
switching.


> and that this is quite a
> precedent.

The precedent that I see here is:

* the public master GNU tool sources use EF_MIPS_ARCH_32 == 5,
  EF_MIPS_ARCH_64 == 6.

* Cygnus/RedHat uses those same values.

* SGI also uses those same values.

* A fair number of other GNU tool or OS support houses have also
  picked up those values and use them.

* Algorithmics uses different values.  The meaning of their 'ALGOR_32'
  arch value hasn't been mentioned here, I don't know what it is.
  But, given that everybody else uses the values that the current GNU
  tools do, well, they should probably provide some backward
  compatibility for their users if they want it, and switch.  (Heck, I
  don't even know that 'ALGOR_32' should be different than '32' to
  begin with.)


> Hopefully the ABI process will soon shake any other
> issues out too.

Indeed.  I look forward to seeing a published ABI proposal.

I strongly encourage you to announce the proposal to other groups than
just the Linux MIPS folks, by the way.  For instance, NetBSD is likely
to want to adopt the same ABI for MIPS platforms, and it would be good
if they were able to participate in the process as well.  I'd
recommend contacting <port-mips@netbsd.org> (the NetBSD/mips
platform-independent development list), and specifically Simon Burge
<simonb@wasabisystems.com> who I believe personally has an interest in
this stuff.


cgd
--
Chris Demetriou                                            Broadcom Corporation
Senior Staff Design Engineer                  Broadband Processor Business Unit
  Any opinions expressed in this message are mine, not necessarily Broadcom's.

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

[Geoff Keating]

> From: cgd@broadcom.com
> Date: 30 Jul 2002 12:20:57 -0700

> Uh, i believe i've seen a snapshot of the Cygnus MIPS32/64 toolchain
> you describe.  It was described to me as an "alpha" snapshot.  I have
> no reason to believe it was ever released as a commercial-quality
> product.

It was.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

[cgd]

At 30 Jul 2002 12:20:57 -0700, Chris G. Demetriou wrote:
> I've made an inquiry, and my understanding is that Cygnus/RedHat
> internally use the same values as the public tools
> (i.e. EF_MIPS_ARCH_MIPS32 == 5, ..._MIPS64 == 6).

Of course, i typo'd most of the names of the constants in my msg.  I
meant E_MIPS_ARCH_32, etc., obviously.  8-)



chris

Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)

[Eric Christopher]

On Tue, 2002-07-30 at 12:27, cgd@broadcom.com wrote:
> At 30 Jul 2002 12:20:57 -0700, Chris G. Demetriou wrote:
> > I've made an inquiry, and my understanding is that Cygnus/RedHat
> > internally use the same values as the public tools
> > (i.e. EF_MIPS_ARCH_MIPS32 == 5, ..._MIPS64 == 6).
> 
> Of course, i typo'd most of the names of the constants in my msg.  I
> meant E_MIPS_ARCH_32, etc., obviously.  8-)

We have nothing different from what the sources on the net use.

-eric

-- 
I don't want a pony, I want a rocket
powered jetpack!