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