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
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 W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +