Subject: bin/4939: mips ELF magic numbers incorrectly assume big-endian host CPU
To: None <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 02/04/1998 18:20:31
>Synopsis: mips ELF magic numbers incorrectly assume big-endian host CPU
>Responsible: bin-bug-people (Utility Bug People)
>Arrival-Date: Wed Feb 4 18:35:00 1998
>Originator: Jonathan Stone
>Release: NetBSD 1.3 (stock)
System: NetBSD Reno.DSG.Stanford.EDU 1.3 NetBSD 1.3 (GENERIC) #2: Tue Dec 30 01:16:36 PST 1997 jonathan@Reno.DSG.Stanford.EDU:/reno/compile/GENERIC pmax
The file(1) magic-number database contains several byteorder-dependent
encodings for MIPS binaries. The entries appear correct for running
on a big-endian MIPS cpu -- the source of the entries - but produce
obvbiously incorrect answers on a little-endian MIPS cpu.
Particularly obnoxious is that little-endian MIPS binaries are misreported
by file(1) running on a little-endian MIPS binary.
This is (understandably) causing woe and confusion to pmax users,
especially first-time users of NetBSD/pmax 1.3.
To show the problems with dynamic binary, ,static binary, and a shared
library, running on a pmax:
file /usr/bin/file; file /bin/date; file /usr/lib/libc.so.12.20
/usr/bin/file: ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order, version 1
/bin/date: ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order, version 1
/usr/lib/libc.so.12.20: ELF 32-bit LSB shared object, MIPS R3000_BE - invalid byte order, version 1
On an i386, running the i386 file(8) command over pmax binaries gives
the same result.
I'm assuming that /usr/share/misc/magic gives the right results on a
NetBSD/pmax ELF binary when run on a big-endian machine, but I dont
thave one around to verify that.
Correct the byteorder bugs in the mips entries in the
/usr/share/misc/magic stanza for ELF files, so that the mips CPU
entries work properly when run on little-endian machines, as well as
on big-endian. This may be as simple as permuting the entries, or
The obvious way to do this is to use byte-by-byte examiniation, to
avoid invalid assumptions about endian-ness of the host CPU doing the
See also my earlier PR on a similar bug in ECOFF encoding in the magic