4 ms·
File isn't smart enough to read too much into the actual ELF format, all it's doing is parsing part of the header. What that difference means is that fasm put
by chaosite 9y ago
File isn't smart enough to read too much into the actual ELF format, all it's doing is parsing part of the header.
What that difference means is that fasm put a 3 in byte 7 of the header, while nasm put a 0 there.
And apparently putting a 0 there no matter what the target OS ABI is common practice.
https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#File_header https://en.wikipedia.org/wiki/Executable_and_Linkable_Format...
- exikyut 9y agoOh! I see! Thanks so much for this little detail - you helped me figure out that in the format ELF64 executable 3 at the top, that 3 is what gets put into the binary! Change it to 0, and sure enough it shows as SYSV. That is cool. ...change it to 2 and it shows as NetBSD ...and 1 makes it show as HP-UX ...4 makes GNU/Hurd O.o 5 is 86Open 6 is Solaris WAT 7 is "Monterey"?!?! (Yup, still executes just fine) 8 is IRIX 9 is FreeBSD 10 is Tru64 O.o 11 is Novell Modesto 12 is OpenBSD 13 and 14 don't display anything, and I presume that's because that's where this madness ends. That was extremely interesting...
- xelxebar 9y agoI've hand-written a couple elf binaries just for kicks. The wikipedia page on ELF has a list of current conventions on the 7th byte in the elf header (e_ident[EI_OSABI] in the spec) [1]: 0x00 System V 0x01 HP-UX 0x02 NetBSD 0x03 Linux 0x04 GNU Hurd 0x06 Solaris 0x07 AIX 0x08 IRIX 0x09 FreeBSD 0x0A Tru64 0x0B Novell Modesto 0x0C OpenBSD 0x0D OpenVMS 0x0E NonStop Kernel 0x0F AROS 0x10 Fenix OS 0x11 CloudABI 0x53 Sortix I don't know enough about linker/loader details, though, to tell you how different ones actually make use of this information. IIRC, the glibc loader just checks that it's 0x0 or 0x3 and leaves it at that. [1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format https://en.wikipedia.org/wiki/Executable_and_Linkable_Format