linux-mips
[Top] [All Lists]

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

To: Carsten Langgaard <carstenl@mips.com>
Subject: Re: [patch] linux: RFC: elf_check_arch() rework
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Thu, 25 Jul 2002 16:12:48 +0200 (MET DST)
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <3D3FFD21.8DA26337@mips.com>
Organization: Technical University of Gdansk
Sender: owner-linux-mips@oss.sgi.com
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        +


<Prev in Thread] Current Thread [Next in Thread>