[patch] linux: RFC: elf_check_arch() rework

[patch] linux: RFC: elf_check_arch() rework

[Maciej W. Rozycki]

Hello,

 After noticing I cannot run a trivial ELF64 program because of the
EF_MIPS_ARCH_3 flag (quite a reasonable setting for a 64-bit executable,
isn't it?), I concluded a considerable rework of elf_check_arch() is
needed as what we currently have is inadequate. 

 Here is my proposal.  I think binfmt_elf.c for mips and binfmt_elf32.c
for mips64 should accept all ELF32 binaries either with no ABI mark (as
produced by most versions of binutils) or with a 32 (aka o32) ABI one and
binfmt_elf.c for mips64 should accept all ELF32 binaries with an n32 ABI
mark and all ELF64 ones (which essentially means the 64 aka n64 ABI). 
Everything else (i.e. o64 and EABIs) is rejected.  The patch adds
necessary ELF file header flag definitions and synchronizes a few wrong
ones to the binutils' definitions as well. 

 It removes the bogus check of architecture flags as they are really
irrelevant -- the code is intended to handle executable formats and not
execution of code.  If a user incorporates unsupported opcodes, he'll just
get SIGILL at one moment.  We may actually check if an architecture is
supported even no other Linux port seems to care, but then the comparison
should be against mips_cpu.isa_level and not against hardcoded constants. 

 Note, this is an RFC at this stage -- I haven't tested the code
adequately for an immediate inclusion, even if it looks obvious.  There
should be no problems with code made with old binutils as unset flags are
treated as (o)32. 

  Maciej

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

patch-mips-2.4.19-rc1-20020719-mips64-elf-2
diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/arch/mips64/kernel/binfmt_elf32.c linux-mips-2.4.19-rc1-20020719/arch/mips64/kernel/binfmt_elf32.c
--- linux-mips-2.4.19-rc1-20020719.macro/arch/mips64/kernel/binfmt_elf32.c	2002-06-29 03:01:44.000000000 +0000
+++ linux-mips-2.4.19-rc1-20020719/arch/mips64/kernel/binfmt_elf32.c	2002-07-23 23:15:27.000000000 +0000
@@ -27,8 +27,26 @@ typedef elf_greg_t elf_gregset_t[ELF_NGR
 typedef double elf_fpreg_t;
 typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
 
-#define elf_check_arch(x)	\
-	((x)->e_machine == EM_MIPS)
+/*
+ * This is used to ensure we don't load something for the wrong architecture.
+ */
+#define elf_check_arch(hdr)						\
+({									\
+	int __res = 1;							\
+	struct elfhdr *__h = (hdr);					\
+									\
+	if (__h->e_machine != EM_MIPS)					\
+		__res = 0;						\
+	if (__h->e_ident[EI_CLASS] != ELFCLASS32)			\
+		__res = 0;						\
+	if ((__h->e_flags & EF_MIPS_ABI2) != 0)				\
+		__res = 0;						\
+	if (((__h->e_flags & EF_MIPS_ABI) != 0) &&			\
+	    ((__h->e_flags & EF_MIPS_ABI) != EF_MIPS_ABI_O32))		\
+		__res = 0;						\
+									\
+	__res;								\
+})
 
 #define TASK32_SIZE		0x80000000UL
 #undef ELF_ET_DYN_BASE
diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips/elf.h linux-mips-2.4.19-rc1-20020719/include/asm-mips/elf.h
--- linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips/elf.h	2002-04-25 02:57:43.000000000 +0000
+++ linux-mips-2.4.19-rc1-20020719/include/asm-mips/elf.h	2002-07-23 22:50:48.000000000 +0000
@@ -16,10 +16,11 @@
 #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.  */
+#define EF_MIPS_ARCH_32     0x50000000  /* MIPS32 code.  */
+#define EF_MIPS_ARCH_64     0x60000000  /* MIPS64 code.  */
+/* The ABI of the file. */
+#define EF_MIPS_ABI_O32     0x00001000  /* O32 ABI.  */
+#define EF_MIPS_ABI_O64     0x00002000  /* O32 extended for 64 bit.  */
 
 typedef unsigned long elf_greg_t;
 typedef elf_greg_t elf_gregset_t[ELF_NGREG];
@@ -37,10 +38,12 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_N
 									\
 	if (__h->e_machine != EM_MIPS)					\
 		__res = 0;						\
-	if (((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_1) &&       	\
-	    ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_2) &&       	\
-	    ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32) &&      	\
-	    ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32R2))      	\
+	if (__h->e_ident[EI_CLASS] != ELFCLASS32)			\
+		__res = 0;						\
+	if ((__h->e_flags & EF_MIPS_ABI2) != 0)				\
+		__res = 0;						\
+	if (((__h->e_flags & EF_MIPS_ABI) != 0) &&			\
+	    ((__h->e_flags & EF_MIPS_ABI) != EF_MIPS_ABI_O32))		\
 		__res = 0;						\
 									\
 	__res;								\
diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips64/elf.h linux-mips-2.4.19-rc1-20020719/include/asm-mips64/elf.h
--- linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips64/elf.h	2002-07-22 08:49:30.000000000 +0000
+++ linux-mips-2.4.19-rc1-20020719/include/asm-mips64/elf.h	2002-07-23 23:12:28.000000000 +0000
@@ -9,21 +9,23 @@
 #include <asm/ptrace.h>
 #include <asm/user.h>
 
-#ifndef ELF_ARCH
-/* ELF register definitions */
-#define ELF_NGREG	45
-#define ELF_NFPREG	33
-
-/* ELF header e_flags defines. MIPS architecture level. */
+/* 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.  */
+#define EF_MIPS_ARCH_32     0x50000000  /* MIPS32 code.  */
+#define EF_MIPS_ARCH_64     0x60000000  /* MIPS64 code.  */
+/* The ABI of the file. */
+#define EF_MIPS_ABI_O32     0x00001000  /* O32 ABI.  */
+#define EF_MIPS_ABI_O64     0x00002000  /* O32 extended for 64 bit.  */
+
+#ifndef ELF_ARCH
+/* ELF register definitions */
+#define ELF_NGREG	45
+#define ELF_NFPREG	33
 
 typedef unsigned long elf_greg_t;
 typedef elf_greg_t elf_gregset_t[ELF_NGREG];
@@ -41,14 +43,9 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_N
 									\
 	if (__h->e_machine != EM_MIPS)					\
 		__res = 0;						\
-	if (sizeof(elf_caddr_t) == 8 &&					\
-	    __h->e_ident[EI_CLASS] == ELFCLASS32)			\
-	        __res = 0;						\
-	if (((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_1) &&	\
-	    ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_2) &&	\
-	    ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32) &&	\
-	    ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32R2))	\
-                __res = 0;						\
+	if ((__h->e_ident[EI_CLASS] == ELFCLASS32) &&			\
+	    ((__h->e_flags & EF_MIPS_ABI2) == 0))			\
+		__res = 0;						\
 									\
 	__res;								\
 })
diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/include/linux/elf.h linux-mips-2.4.19-rc1-20020719/include/linux/elf.h
--- linux-mips-2.4.19-rc1-20020719.macro/include/linux/elf.h	2002-07-22 08:49:30.000000000 +0000
+++ linux-mips-2.4.19-rc1-20020719/include/linux/elf.h	2002-07-23 22:18:54.000000000 +0000
@@ -37,6 +37,9 @@ typedef __s64	Elf64_Sxword;
 #define EF_MIPS_NOREORDER 0x00000001
 #define EF_MIPS_PIC       0x00000002
 #define EF_MIPS_CPIC      0x00000004
+#define EF_MIPS_ABI2      0x00000020
+#define EF_MIPS_32BITMODE 0x00000100
+#define EF_MIPS_ABI       0x0000f000
 #define EF_MIPS_ARCH      0xf0000000
 
 /* These constants define the different elf file types */

Re: [patch] linux: RFC: elf_check_arch() rework

[Daniel Jacobowitz]

On Wed, Jul 24, 2002 at 07:05:36PM +0200, Maciej W. Rozycki wrote:
> Hello,
> 
>  After noticing I cannot run a trivial ELF64 program because of the
> EF_MIPS_ARCH_3 flag (quite a reasonable setting for a 64-bit executable,
> isn't it?), I concluded a considerable rework of elf_check_arch() is
> needed as what we currently have is inadequate. 
> 
>  Here is my proposal.  I think binfmt_elf.c for mips and binfmt_elf32.c
> for mips64 should accept all ELF32 binaries either with no ABI mark (as
> produced by most versions of binutils) or with a 32 (aka o32) ABI one and
> binfmt_elf.c for mips64 should accept all ELF32 binaries with an n32 ABI
> mark and all ELF64 ones (which essentially means the 64 aka n64 ABI). 
> Everything else (i.e. o64 and EABIs) is rejected.  The patch adds
> necessary ELF file header flag definitions and synchronizes a few wrong
> ones to the binutils' definitions as well. 
> 
>  It removes the bogus check of architecture flags as they are really
> irrelevant -- the code is intended to handle executable formats and not
> execution of code.  If a user incorporates unsupported opcodes, he'll just
> get SIGILL at one moment.  We may actually check if an architecture is
> supported even no other Linux port seems to care, but then the comparison
> should be against mips_cpu.isa_level and not against hardcoded constants. 
> 
>  Note, this is an RFC at this stage -- I haven't tested the code
> adequately for an immediate inclusion, even if it looks obvious.  There
> should be no problems with code made with old binutils as unset flags are
> treated as (o)32. 

Well, that sounds like the right approach to me.  It sounds like
there's some real progress on the 64-bit tools now...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] linux: RFC: elf_check_arch() rework

[Carsten Langgaard]

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

Hope that makes some sense.
/Carsten


"Maciej W. Rozycki" wrote:

> Hello,
>
>  After noticing I cannot run a trivial ELF64 program because of the
> EF_MIPS_ARCH_3 flag (quite a reasonable setting for a 64-bit executable,
> isn't it?), I concluded a considerable rework of elf_check_arch() is
> needed as what we currently have is inadequate.
>
>  Here is my proposal.  I think binfmt_elf.c for mips and binfmt_elf32.c
> for mips64 should accept all ELF32 binaries either with no ABI mark (as
> produced by most versions of binutils) or with a 32 (aka o32) ABI one and
> binfmt_elf.c for mips64 should accept all ELF32 binaries with an n32 ABI
> mark and all ELF64 ones (which essentially means the 64 aka n64 ABI).
> Everything else (i.e. o64 and EABIs) is rejected.  The patch adds
> necessary ELF file header flag definitions and synchronizes a few wrong
> ones to the binutils' definitions as well.
>
>  It removes the bogus check of architecture flags as they are really
> irrelevant -- the code is intended to handle executable formats and not
> execution of code.  If a user incorporates unsupported opcodes, he'll just
> get SIGILL at one moment.  We may actually check if an architecture is
> supported even no other Linux port seems to care, but then the comparison
> should be against mips_cpu.isa_level and not against hardcoded constants.
>
>  Note, this is an RFC at this stage -- I haven't tested the code
> adequately for an immediate inclusion, even if it looks obvious.  There
> should be no problems with code made with old binutils as unset flags are
> treated as (o)32.
>
>   Maciej
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
>
> patch-mips-2.4.19-rc1-20020719-mips64-elf-2
> diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/arch/mips64/kernel/binfmt_elf32.c linux-mips-2.4.19-rc1-20020719/arch/mips64/kernel/binfmt_elf32.c
> --- linux-mips-2.4.19-rc1-20020719.macro/arch/mips64/kernel/binfmt_elf32.c      2002-06-29 03:01:44.000000000 +0000
> +++ linux-mips-2.4.19-rc1-20020719/arch/mips64/kernel/binfmt_elf32.c    2002-07-23 23:15:27.000000000 +0000
> @@ -27,8 +27,26 @@ typedef elf_greg_t elf_gregset_t[ELF_NGR
>  typedef double elf_fpreg_t;
>  typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>
> -#define elf_check_arch(x)      \
> -       ((x)->e_machine == EM_MIPS)
> +/*
> + * This is used to ensure we don't load something for the wrong architecture.
> + */
> +#define elf_check_arch(hdr)                                            \
> +({                                                                     \
> +       int __res = 1;                                                  \
> +       struct elfhdr *__h = (hdr);                                     \
> +                                                                       \
> +       if (__h->e_machine != EM_MIPS)                                  \
> +               __res = 0;                                              \
> +       if (__h->e_ident[EI_CLASS] != ELFCLASS32)                       \
> +               __res = 0;                                              \
> +       if ((__h->e_flags & EF_MIPS_ABI2) != 0)                         \
> +               __res = 0;                                              \
> +       if (((__h->e_flags & EF_MIPS_ABI) != 0) &&                      \
> +           ((__h->e_flags & EF_MIPS_ABI) != EF_MIPS_ABI_O32))          \
> +               __res = 0;                                              \
> +                                                                       \
> +       __res;                                                          \
> +})
>
>  #define TASK32_SIZE            0x80000000UL
>  #undef ELF_ET_DYN_BASE
> diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips/elf.h linux-mips-2.4.19-rc1-20020719/include/asm-mips/elf.h
> --- linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips/elf.h 2002-04-25 02:57:43.000000000 +0000
> +++ linux-mips-2.4.19-rc1-20020719/include/asm-mips/elf.h       2002-07-23 22:50:48.000000000 +0000
> @@ -16,10 +16,11 @@
>  #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.  */
> +#define EF_MIPS_ARCH_32     0x50000000  /* MIPS32 code.  */
> +#define EF_MIPS_ARCH_64     0x60000000  /* MIPS64 code.  */
> +/* The ABI of the file. */
> +#define EF_MIPS_ABI_O32     0x00001000  /* O32 ABI.  */
> +#define EF_MIPS_ABI_O64     0x00002000  /* O32 extended for 64 bit.  */
>
>  typedef unsigned long elf_greg_t;
>  typedef elf_greg_t elf_gregset_t[ELF_NGREG];
> @@ -37,10 +38,12 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_N
>                                                                         \
>         if (__h->e_machine != EM_MIPS)                                  \
>                 __res = 0;                                              \
> -       if (((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_1) &&        \
> -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_2) &&        \
> -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32) &&       \
> -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32R2))       \
> +       if (__h->e_ident[EI_CLASS] != ELFCLASS32)                       \
> +               __res = 0;                                              \
> +       if ((__h->e_flags & EF_MIPS_ABI2) != 0)                         \
> +               __res = 0;                                              \
> +       if (((__h->e_flags & EF_MIPS_ABI) != 0) &&                      \
> +           ((__h->e_flags & EF_MIPS_ABI) != EF_MIPS_ABI_O32))          \
>                 __res = 0;                                              \
>                                                                         \
>         __res;                                                          \
> diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips64/elf.h linux-mips-2.4.19-rc1-20020719/include/asm-mips64/elf.h
> --- linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips64/elf.h       2002-07-22 08:49:30.000000000 +0000
> +++ linux-mips-2.4.19-rc1-20020719/include/asm-mips64/elf.h     2002-07-23 23:12:28.000000000 +0000
> @@ -9,21 +9,23 @@
>  #include <asm/ptrace.h>
>  #include <asm/user.h>
>
> -#ifndef ELF_ARCH
> -/* ELF register definitions */
> -#define ELF_NGREG      45
> -#define ELF_NFPREG     33
> -
> -/* ELF header e_flags defines. MIPS architecture level. */
> +/* 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.  */
> +#define EF_MIPS_ARCH_32     0x50000000  /* MIPS32 code.  */
> +#define EF_MIPS_ARCH_64     0x60000000  /* MIPS64 code.  */
> +/* The ABI of the file. */
> +#define EF_MIPS_ABI_O32     0x00001000  /* O32 ABI.  */
> +#define EF_MIPS_ABI_O64     0x00002000  /* O32 extended for 64 bit.  */
> +
> +#ifndef ELF_ARCH
> +/* ELF register definitions */
> +#define ELF_NGREG      45
> +#define ELF_NFPREG     33
>
>  typedef unsigned long elf_greg_t;
>  typedef elf_greg_t elf_gregset_t[ELF_NGREG];
> @@ -41,14 +43,9 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_N
>                                                                         \
>         if (__h->e_machine != EM_MIPS)                                  \
>                 __res = 0;                                              \
> -       if (sizeof(elf_caddr_t) == 8 &&                                 \
> -           __h->e_ident[EI_CLASS] == ELFCLASS32)                       \
> -               __res = 0;                                              \
> -       if (((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_1) &&        \
> -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_2) &&        \
> -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32) &&       \
> -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32R2))       \
> -                __res = 0;                                             \
> +       if ((__h->e_ident[EI_CLASS] == ELFCLASS32) &&                   \
> +           ((__h->e_flags & EF_MIPS_ABI2) == 0))                       \
> +               __res = 0;                                              \
>                                                                         \
>         __res;                                                          \
>  })
> diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/include/linux/elf.h linux-mips-2.4.19-rc1-20020719/include/linux/elf.h
> --- linux-mips-2.4.19-rc1-20020719.macro/include/linux/elf.h    2002-07-22 08:49:30.000000000 +0000
> +++ linux-mips-2.4.19-rc1-20020719/include/linux/elf.h  2002-07-23 22:18:54.000000000 +0000
> @@ -37,6 +37,9 @@ typedef __s64 Elf64_Sxword;
>  #define EF_MIPS_NOREORDER 0x00000001
>  #define EF_MIPS_PIC       0x00000002
>  #define EF_MIPS_CPIC      0x00000004
> +#define EF_MIPS_ABI2      0x00000020
> +#define EF_MIPS_32BITMODE 0x00000100
> +#define EF_MIPS_ABI       0x0000f000
>  #define EF_MIPS_ARCH      0xf0000000
>
>  /* These constants define the different elf file types */

Re: [patch] linux: RFC: elf_check_arch() rework

[Daniel Jacobowitz]

On Wed, Jul 24, 2002 at 09:12:20PM +0200, 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. I don't see that is wrong

Well, if so you'd better be using the ones Maciej changed them to, not
the ones they used to be.  Check binutils/include/elf/mips.h for the
current definitions of these flags; the kernel was just 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. You are

I agree with Maciej on this.  It is perfectly reasonable to build a
binary which can operate safely at a different ISA level (either above
or below) that which it is linked at; and rather than arguing about the
semantics of that, as he also pointed out, this routine is specifically
supposed to be checking architecture and not ISA level; consistency
across platforms has high advantages.

> 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.
> 
> Hope that makes some sense.
> /Carsten
> 
> 
> "Maciej W. Rozycki" wrote:
> 
> > Hello,
> >
> >  After noticing I cannot run a trivial ELF64 program because of the
> > EF_MIPS_ARCH_3 flag (quite a reasonable setting for a 64-bit executable,
> > isn't it?), I concluded a considerable rework of elf_check_arch() is
> > needed as what we currently have is inadequate.
> >
> >  Here is my proposal.  I think binfmt_elf.c for mips and binfmt_elf32.c
> > for mips64 should accept all ELF32 binaries either with no ABI mark (as
> > produced by most versions of binutils) or with a 32 (aka o32) ABI one and
> > binfmt_elf.c for mips64 should accept all ELF32 binaries with an n32 ABI
> > mark and all ELF64 ones (which essentially means the 64 aka n64 ABI).
> > Everything else (i.e. o64 and EABIs) is rejected.  The patch adds
> > necessary ELF file header flag definitions and synchronizes a few wrong
> > ones to the binutils' definitions as well.
> >
> >  It removes the bogus check of architecture flags as they are really
> > irrelevant -- the code is intended to handle executable formats and not
> > execution of code.  If a user incorporates unsupported opcodes, he'll just
> > get SIGILL at one moment.  We may actually check if an architecture is
> > supported even no other Linux port seems to care, but then the comparison
> > should be against mips_cpu.isa_level and not against hardcoded constants.
> >
> >  Note, this is an RFC at this stage -- I haven't tested the code
> > adequately for an immediate inclusion, even if it looks obvious.  There
> > should be no problems with code made with old binutils as unset flags are
> > treated as (o)32.
> >
> >   Maciej
> >
> > --
> > +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> > +--------------------------------------------------------------+
> > +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> >
> > patch-mips-2.4.19-rc1-20020719-mips64-elf-2
> > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/arch/mips64/kernel/binfmt_elf32.c linux-mips-2.4.19-rc1-20020719/arch/mips64/kernel/binfmt_elf32.c
> > --- linux-mips-2.4.19-rc1-20020719.macro/arch/mips64/kernel/binfmt_elf32.c      2002-06-29 03:01:44.000000000 +0000
> > +++ linux-mips-2.4.19-rc1-20020719/arch/mips64/kernel/binfmt_elf32.c    2002-07-23 23:15:27.000000000 +0000
> > @@ -27,8 +27,26 @@ typedef elf_greg_t elf_gregset_t[ELF_NGR
> >  typedef double elf_fpreg_t;
> >  typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
> >
> > -#define elf_check_arch(x)      \
> > -       ((x)->e_machine == EM_MIPS)
> > +/*
> > + * This is used to ensure we don't load something for the wrong architecture.
> > + */
> > +#define elf_check_arch(hdr)                                            \
> > +({                                                                     \
> > +       int __res = 1;                                                  \
> > +       struct elfhdr *__h = (hdr);                                     \
> > +                                                                       \
> > +       if (__h->e_machine != EM_MIPS)                                  \
> > +               __res = 0;                                              \
> > +       if (__h->e_ident[EI_CLASS] != ELFCLASS32)                       \
> > +               __res = 0;                                              \
> > +       if ((__h->e_flags & EF_MIPS_ABI2) != 0)                         \
> > +               __res = 0;                                              \
> > +       if (((__h->e_flags & EF_MIPS_ABI) != 0) &&                      \
> > +           ((__h->e_flags & EF_MIPS_ABI) != EF_MIPS_ABI_O32))          \
> > +               __res = 0;                                              \
> > +                                                                       \
> > +       __res;                                                          \
> > +})
> >
> >  #define TASK32_SIZE            0x80000000UL
> >  #undef ELF_ET_DYN_BASE
> > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips/elf.h linux-mips-2.4.19-rc1-20020719/include/asm-mips/elf.h
> > --- linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips/elf.h 2002-04-25 02:57:43.000000000 +0000
> > +++ linux-mips-2.4.19-rc1-20020719/include/asm-mips/elf.h       2002-07-23 22:50:48.000000000 +0000
> > @@ -16,10 +16,11 @@
> >  #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.  */
> > +#define EF_MIPS_ARCH_32     0x50000000  /* MIPS32 code.  */
> > +#define EF_MIPS_ARCH_64     0x60000000  /* MIPS64 code.  */
> > +/* The ABI of the file. */
> > +#define EF_MIPS_ABI_O32     0x00001000  /* O32 ABI.  */
> > +#define EF_MIPS_ABI_O64     0x00002000  /* O32 extended for 64 bit.  */
> >
> >  typedef unsigned long elf_greg_t;
> >  typedef elf_greg_t elf_gregset_t[ELF_NGREG];
> > @@ -37,10 +38,12 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_N
> >                                                                         \
> >         if (__h->e_machine != EM_MIPS)                                  \
> >                 __res = 0;                                              \
> > -       if (((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_1) &&        \
> > -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_2) &&        \
> > -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32) &&       \
> > -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32R2))       \
> > +       if (__h->e_ident[EI_CLASS] != ELFCLASS32)                       \
> > +               __res = 0;                                              \
> > +       if ((__h->e_flags & EF_MIPS_ABI2) != 0)                         \
> > +               __res = 0;                                              \
> > +       if (((__h->e_flags & EF_MIPS_ABI) != 0) &&                      \
> > +           ((__h->e_flags & EF_MIPS_ABI) != EF_MIPS_ABI_O32))          \
> >                 __res = 0;                                              \
> >                                                                         \
> >         __res;                                                          \
> > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips64/elf.h linux-mips-2.4.19-rc1-20020719/include/asm-mips64/elf.h
> > --- linux-mips-2.4.19-rc1-20020719.macro/include/asm-mips64/elf.h       2002-07-22 08:49:30.000000000 +0000
> > +++ linux-mips-2.4.19-rc1-20020719/include/asm-mips64/elf.h     2002-07-23 23:12:28.000000000 +0000
> > @@ -9,21 +9,23 @@
> >  #include <asm/ptrace.h>
> >  #include <asm/user.h>
> >
> > -#ifndef ELF_ARCH
> > -/* ELF register definitions */
> > -#define ELF_NGREG      45
> > -#define ELF_NFPREG     33
> > -
> > -/* ELF header e_flags defines. MIPS architecture level. */
> > +/* 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.  */
> > +#define EF_MIPS_ARCH_32     0x50000000  /* MIPS32 code.  */
> > +#define EF_MIPS_ARCH_64     0x60000000  /* MIPS64 code.  */
> > +/* The ABI of the file. */
> > +#define EF_MIPS_ABI_O32     0x00001000  /* O32 ABI.  */
> > +#define EF_MIPS_ABI_O64     0x00002000  /* O32 extended for 64 bit.  */
> > +
> > +#ifndef ELF_ARCH
> > +/* ELF register definitions */
> > +#define ELF_NGREG      45
> > +#define ELF_NFPREG     33
> >
> >  typedef unsigned long elf_greg_t;
> >  typedef elf_greg_t elf_gregset_t[ELF_NGREG];
> > @@ -41,14 +43,9 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_N
> >                                                                         \
> >         if (__h->e_machine != EM_MIPS)                                  \
> >                 __res = 0;                                              \
> > -       if (sizeof(elf_caddr_t) == 8 &&                                 \
> > -           __h->e_ident[EI_CLASS] == ELFCLASS32)                       \
> > -               __res = 0;                                              \
> > -       if (((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_1) &&        \
> > -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_2) &&        \
> > -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32) &&       \
> > -           ((__h->e_flags & EF_MIPS_ARCH) != EF_MIPS_ARCH_32R2))       \
> > -                __res = 0;                                             \
> > +       if ((__h->e_ident[EI_CLASS] == ELFCLASS32) &&                   \
> > +           ((__h->e_flags & EF_MIPS_ABI2) == 0))                       \
> > +               __res = 0;                                              \
> >                                                                         \
> >         __res;                                                          \
> >  })
> > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/include/linux/elf.h linux-mips-2.4.19-rc1-20020719/include/linux/elf.h
> > --- linux-mips-2.4.19-rc1-20020719.macro/include/linux/elf.h    2002-07-22 08:49:30.000000000 +0000
> > +++ linux-mips-2.4.19-rc1-20020719/include/linux/elf.h  2002-07-23 22:18:54.000000000 +0000
> > @@ -37,6 +37,9 @@ typedef __s64 Elf64_Sxword;
> >  #define EF_MIPS_NOREORDER 0x00000001
> >  #define EF_MIPS_PIC       0x00000002
> >  #define EF_MIPS_CPIC      0x00000004
> > +#define EF_MIPS_ABI2      0x00000020
> > +#define EF_MIPS_32BITMODE 0x00000100
> > +#define EF_MIPS_ABI       0x0000f000
> >  #define EF_MIPS_ARCH      0xf0000000
> >
> >  /* These constants define the different elf file types */
> 
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] linux: RFC: elf_check_arch() rework

[Maciej W. Rozycki]

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

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

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

Re: [patch] linux: RFC: elf_check_arch() rework

[Carsten Langgaard]

"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

Re: [patch] linux: RFC: elf_check_arch() rework

[Maciej W. Rozycki]

On Thu, 25 Jul 2002, Carsten Langgaard wrote:

> Shouldn't it be the other way around, the real world should follow the spec
> ;-)

 Where is the spec?  If one were clearly available, the world would
follow.  Otherwise, having no other definite reference BFD is *the* spec,
as usual (see Alpha/ELF for another example).

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

 OK, but please show me a document.  I only have a vague definition of
values in the 0 - 3 range in the SGI's (n)64 ABI draft.  There is no
definition provided at the master SysV site (i.e. currently
'http://stage.caldera.com/developer/devspecs/') and the mipsabi.org site
no longer exists.

 BTW, what are the two last entries meant to define, specifically, how do
they differ from the preceding two? 

> If you look at the elf.h file in glibc, the you will see, it has the same
> values as the kernel.

 I've seen it and currently it's broken, since real binaries (as created
by binutils) define the values differently. 

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

 Then please send a proposal to the binutils list ASAP, as code marked as
MIPS32/64 can be already generated by binutils for quite some time now.  I
don't care personally, at least not yet, but others may do. 

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

 You need to add an error code to <errno.h>, then, and a suitable error
message to be emitted by perror() and friends.  Currently I see none that
fits.  I'm not sure if the various *nix standards provide any support for
such functionality, but it might be worthwhile to add.

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

 The code would be rejected by elf_check_arch() as it would have to be
marked as "n32" or "64" (or "o64", or a kind of EABI, but we don't support
these) to make use of 64-bit registers.  Gcc and gas won't emit 64-bit
operations for any ISA (but they may make use of additional instructions
defined by the ISA, as long as they operate on 32-bit data) if the
selected ABI doesn't permit them (modulo possible bugs, certainly, as the
64-bit support bits are not tested sufficiently, yet, but that's the
intent).  If you handcode 64-bit operations in assembly, then you are
fully responsible for the results and that won't be reflected in the ELF
header anyway, as ".set" directives do not affect it. 

  Maciej

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

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)

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

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