Executable and Linkable Format

Last updated
Executable and Linkable Format
Filename extension
none, .axf, .bin, .elf, .o, .out, .prx, .puff, .ko, .mod, and .so
Magic number 0x7F 'E' 'L' 'F'
Developed by Unix System Laboratories [1] :3
Type of format Binary, executable, object, shared library, core dump
Container for Many executable binary formats
An ELF file has two views: the program header shows the segments used at run time, whereas the section header lists the set of sections. Elf-layout--en.svg
An ELF file has two views: the program header shows the segments used at run time, whereas the section header lists the set of sections.

In computing, the Executable and Linkable Format [2] (ELF, formerly named Extensible Linking Format), is a common standard file format for executable files, object code, shared libraries, and core dumps. First published in the specification for the application binary interface (ABI) of the Unix operating system version named System V Release 4 (SVR4), [3] and later in the Tool Interface Standard, [1] it was quickly accepted among different vendors of Unix systems. In 1999, it was chosen as the standard binary file format for Unix and Unix-like systems on x86 processors by the 86open project.

Contents

By design, the ELF format is flexible, extensible, and cross-platform. For instance, it supports different endiannesses and address sizes so it does not exclude any particular CPU or instruction set architecture. This has allowed it to be adopted by many different operating systems on many different hardware platforms.

File layout

Each ELF file is made up of one ELF header, followed by file data. The data can include:

Structure of an ELF file with key entries highlighted ELF Executable and Linkable Format diagram by Ange Albertini.png
Structure of an ELF file with key entries highlighted

The segments contain information that is needed for run time execution of the file, while sections contain important data for linking and relocation. Any byte in the entire file can be owned by one section at most, and orphan bytes can occur which are unowned by any section.

000000007f454c46020101000000000000000000|.ELF............|

0000001002003e0001000000c548400000000000|..>......H@.....|

Example hexdump of ELF file header [4]

File header

The ELF header defines whether to use 32-bit or 64-bit addresses. The header contains three fields that are affected by this setting and offset other fields that follow them. The ELF header is 52 or 64 bytes long for 32-bit and 64-bit binaries respectively.

ELF header [5]
OffsetSize (bytes)FieldPurpose
32-bit64-bit32-bit64-bit
0x004e_ident[EI_MAG0] through e_ident[EI_MAG3]0x7F followed by ELF(45 4c 46) in ASCII; these four bytes constitute the magic number.
0x041e_ident[EI_CLASS]This byte is set to either 1 or 2 to signify 32- or 64-bit format, respectively.
0x051e_ident[EI_DATA]This byte is set to either 1 or 2 to signify little or big endianness, respectively. This affects interpretation of multi-byte fields starting with offset 0x10.
0x061e_ident[EI_VERSION]Set to 1 for the original and current version of ELF.
0x071e_ident[EI_OSABI]Identifies the target operating system ABI.
ValueABI
0x00 System V
0x01 HP-UX
0x02 NetBSD
0x03 Linux
0x04 GNU Hurd
0x06 Solaris
0x07 AIX (Monterey)
0x08 IRIX
0x09 FreeBSD
0x0A Tru64
0x0BNovell Modesto
0x0C OpenBSD
0x0D OpenVMS
0x0E NonStop Kernel
0x0F AROS
0x10FenixOS
0x11Nuxi CloudABI
0x12 Stratus Technologies OpenVOS
0x081e_ident[EI_ABIVERSION]Further specifies the ABI version. Its interpretation depends on the target ABI. Linux kernel (after at least 2.6) has no definition of it, [6] so it is ignored for statically-linked executables. In that case, offset and size of EI_PAD are 8.

glibc 2.12+ in case e_ident[EI_OSABI] == 3 treats this field as ABI version of the dynamic linker: [7] it defines a list of dynamic linker's features, [8] treats e_ident[EI_ABIVERSION] as a feature level requested by the shared object (executable or dynamic library) and refuses to load it if an unknown feature is requested, i.e. e_ident[EI_ABIVERSION] is greater than the largest known feature. [9]

0x097e_ident[EI_PAD]Reserved padding bytes. Currently unused. Should be filled with zeros and ignored when read.
0x102e_typeIdentifies object file type.
ValueTypeMeaning
0x00ET_NONEUnknown.
0x01ET_RELRelocatable file.
0x02ET_EXECExecutable file.
0x03ET_DYNShared object.
0x04ET_CORECore file.
0xFE00ET_LOOSReserved inclusive range. Operating system specific.
0xFEFFET_HIOS
0xFF00ET_LOPROCReserved inclusive range. Processor specific.
0xFFFFET_HIPROC
0x122e_machineSpecifies target instruction set architecture. Some examples are:
ValueISA
0x00No specific instruction set
0x01 AT&T WE 32100
0x02 SPARC
0x03 x86
0x04 Motorola 68000 (M68k)
0x05 Motorola 88000 (M88k)
0x06 Intel MCU
0x07 Intel 80860
0x08 MIPS
0x09 IBM System/370
0x0A MIPS RS3000 Little-endian
0x0B - 0x0EReserved for future use
0x0F Hewlett-Packard PA-RISC
0x13 Intel 80960
0x14 PowerPC
0x15 PowerPC (64-bit)
0x16 S390, including S390x
0x17IBM SPU/SPC
0x18 - 0x23Reserved for future use
0x24 NEC V800
0x25Fujitsu FR20
0x26 TRW RH-32
0x27Motorola RCE
0x28 Arm (up to Armv7/AArch32)
0x29 Digital Alpha
0x2A SuperH
0x2B SPARC Version 9
0x2C Siemens TriCore embedded processor
0x2D Argonaut RISC Core
0x2E Hitachi H8/300
0x2F Hitachi H8/300H
0x30 Hitachi H8S
0x31 Hitachi H8/500
0x32 IA-64
0x33 Stanford MIPS-X
0x34 Motorola ColdFire
0x35 Motorola M68HC12
0x36Fujitsu MMA Multimedia Accelerator
0x37Siemens PCP
0x38 Sony nCPU embedded RISC processor
0x39Denso NDR1 microprocessor
0x3AMotorola Star*Core processor
0x3BToyota ME16 processor
0x3CSTMicroelectronics ST100 processor
0x3DAdvanced Logic Corp. TinyJ embedded processor family
0x3E AMD x86-64
0x3FSony DSP Processor
0x40 Digital Equipment Corp. PDP-10
0x41 Digital Equipment Corp. PDP-11
0x42Siemens FX66 microcontroller
0x43STMicroelectronics ST9+ 8/16 bit microcontroller
0x44STMicroelectronics ST7 8-bit microcontroller
0x45 Motorola MC68HC16 Microcontroller
0x46 Motorola MC68HC11 Microcontroller
0x47 Motorola MC68HC08 Microcontroller
0x48 Motorola MC68HC05 Microcontroller
0x49Silicon Graphics SVx
0x4ASTMicroelectronics ST19 8-bit microcontroller
0x4B Digital VAX
0x4CAxis Communications 32-bit embedded processor
0x4DInfineon Technologies 32-bit embedded processor
0x4EElement 14 64-bit DSP Processor
0x4FLSI Logic 16-bit DSP Processor
0x8C TMS320C6000 Family
0xAF MCST Elbrus e2k
0xB7 Arm 64-bits (Armv8/AArch64)
0xDC Zilog Z80
0xF3 RISC-V
0xF7 Berkeley Packet Filter
0x101 WDC 65C816
0x144e_versionSet to 1 for the original version of ELF.
0x1848e_entryThis is the memory address of the entry point from where the process starts executing. This field is either 32 or 64 bits long, depending on the format defined earlier (byte 0x04). If the file doesn't have an associated entry point, then this holds zero.
0x1C0x2048e_phoffPoints to the start of the program header table. It usually follows the file header immediately following this one, making the offset 0x34 or 0x40 for 32- and 64-bit ELF executables, respectively.
0x200x2848e_shoffPoints to the start of the section header table.
0x240x304e_flagsInterpretation of this field depends on the target architecture.
0x280x342e_ehsizeContains the size of this header, normally 64 Bytes for 64-bit and 52 Bytes for 32-bit format.
0x2A0x362e_phentsizeContains the size of a program header table entry. As explained below, this will typically be 0x20 (32 bit) or 0x38 (64 bit).
0x2C0x382e_phnumContains the number of entries in the program header table.
0x2E0x3A2e_shentsizeContains the size of a section header table entry. As explained below, this will typically be 0x28 (32 bit) or 0x40 (64 bit).
0x300x3C2e_shnumContains the number of entries in the section header table.
0x320x3E2e_shstrndxContains index of the section header table entry that contains the section names.
0x340x40End of ELF Header (size).

Program header

The program header table tells the system how to create a process image. It is found at file offset e_phoff, and consists of e_phnum entries, each with size e_phentsize. The layout is slightly different in 32-bit ELF vs 64-bit ELF, because the p_flags are in a different structure location for alignment reasons. Each entry is structured as:

Program header [10]
OffsetSize (bytes)FieldPurpose
32-bit64-bit32-bit64-bit
0x004p_typeIdentifies the type of the segment.
ValueNameMeaning
0x00000000PT_NULLProgram header table entry unused.
0x00000001PT_LOADLoadable segment.
0x00000002PT_DYNAMICDynamic linking information.
0x00000003PT_INTERPInterpreter information.
0x00000004PT_NOTEAuxiliary information.
0x00000005PT_SHLIBReserved.
0x00000006PT_PHDRSegment containing program header table itself.
0x00000007PT_TLSThread-Local Storage template.
0x60000000PT_LOOSReserved inclusive range. Operating system specific.
0x6FFFFFFFPT_HIOS
0x70000000PT_LOPROCReserved inclusive range. Processor specific.
0x7FFFFFFFPT_HIPROC
0x044p_flagsSegment-dependent flags (position for 64-bit structure).
ValueNameMeaning
0x1PF_XExecutable segment.
0x2PF_WWriteable segment.
0x4PF_RReadable segment.
0x040x0848p_offsetOffset of the segment in the file image.
0x080x1048p_vaddrVirtual address of the segment in memory.
0x0C0x1848p_paddrOn systems where physical address is relevant, reserved for segment's physical address.
0x100x2048p_fileszSize in bytes of the segment in the file image. May be 0.
0x140x2848p_memszSize in bytes of the segment in memory. May be 0.
0x184p_flagsSegment-dependent flags (position for 32-bit structure). See above p_flags field for flag definitions.
0x1C0x3048p_align0 and 1 specify no alignment. Otherwise should be a positive, integral power of 2, with p_vaddr equating p_offset modulus p_align.
0x200x38End of Program Header (size).

Section header

OffsetSize (bytes)FieldPurpose
32-bit64-bit32-bit64-bit
0x004sh_nameAn offset to a string in the .shstrtab section that represents the name of this section.
0x044sh_typeIdentifies the type of this header.
ValueNameMeaning
0x0SHT_NULLSection header table entry unused
0x1SHT_PROGBITSProgram data
0x2SHT_SYMTABSymbol table
0x3SHT_STRTABString table
0x4SHT_RELARelocation entries with addends
0x5SHT_HASHSymbol hash table
0x6SHT_DYNAMICDynamic linking information
0x7SHT_NOTENotes
0x8SHT_NOBITSProgram space with no data (bss)
0x9SHT_RELRelocation entries, no addends
0x0ASHT_SHLIBReserved
0x0BSHT_DYNSYMDynamic linker symbol table
0x0ESHT_INIT_ARRAYArray of constructors
0x0FSHT_FINI_ARRAYArray of destructors
0x10SHT_PREINIT_ARRAYArray of pre-constructors
0x11SHT_GROUPSection group
0x12SHT_SYMTAB_SHNDXExtended section indices
0x13SHT_NUMNumber of defined types.
0x60000000SHT_LOOSStart OS-specific.
.........
0x0848sh_flagsIdentifies the attributes of the section.
ValueNameMeaning
0x1SHF_WRITEWritable
0x2SHF_ALLOCOccupies memory during execution
0x4SHF_EXECINSTRExecutable
0x10SHF_MERGEMight be merged
0x20SHF_STRINGSContains null-terminated strings
0x40SHF_INFO_LINK'sh_info' contains SHT index
0x80SHF_LINK_ORDERPreserve order after combining
0x100SHF_OS_NONCONFORMINGNon-standard OS specific handling required
0x200SHF_GROUPSection is member of a group
0x400SHF_TLSSection hold thread-local data
0x0FF00000SHF_MASKOSOS-specific
0xF0000000SHF_MASKPROCProcessor-specific
0x4000000SHF_ORDEREDSpecial ordering requirement (Solaris)
0x8000000SHF_EXCLUDESection is excluded unless referenced or allocated (Solaris)
0x0C0x1048sh_addrVirtual address of the section in memory, for sections that are loaded.
0x100x1848sh_offsetOffset of the section in the file image.
0x140x2048sh_sizeSize in bytes of the section in the file image. May be 0.
0x180x284sh_linkContains the section index of an associated section. This field is used for several purposes, depending on the type of section.
0x1C0x2C4sh_infoContains extra information about the section. This field is used for several purposes, depending on the type of section.
0x200x3048sh_addralignContains the required alignment of the section. This field must be a power of two.
0x240x3848sh_entsizeContains the size, in bytes, of each entry, for sections that contain fixed-size entries. Otherwise, this field contains zero.
0x280x40End of Section Header (size).

Tools

Applications

Unix-like systems

The ELF format has replaced older executable formats in various environments. It has replaced a.out and COFF formats in Unix-like operating systems:

Non-Unix adoption

ELF has also seen some adoption in non-Unix operating systems, such as:

Microsoft Windows also uses the ELF format, but only for its Windows Subsystem for Linux compatibility system. [17]

Game consoles

Some game consoles also use ELF:

PowerPC

Other (operating) systems running on PowerPC that use ELF:

Mobile phones

Some operating systems for mobile phones and mobile devices use ELF:

Some phones can run ELF files through the use of a patch that adds assembly code to the main firmware, which is a feature known as ELFPack in the underground modding culture. The ELF file format is also used with the Atmel AVR (8-bit), AVR32 [22] and with Texas Instruments MSP430 microcontroller architectures. Some implementations of Open Firmware can also load ELF files, most notably Apple's implementation used in almost all PowerPC machines the company produced.

Specifications

The Linux Standard Base (LSB) supplements some of the above specifications for architectures in which it is specified. [23] For example, that is the case for the System V ABI, AMD64 Supplement. [24] [25]

86open

86open was a project to form consensus on a common binary file format for Unix and Unix-like operating systems on the common PC compatible x86 architecture, to encourage software developers to port to the architecture. [26] The initial idea was to standardize on a small subset of Spec 1170, a predecessor of the Single UNIX Specification, and the GNU C Library (glibc) to enable unmodified binaries to run on the x86 Unix-like operating systems. The project was originally designated "Spec 150".

The format eventually chosen was ELF, specifically the Linux implementation of ELF, after it had turned out to be a de facto standard supported by all involved vendors and operating systems.

The group began email discussions in 1997 and first met together at the Santa Cruz Operation offices on August 22, 1997.

The steering committee was Marc Ewing, Dion Johnson, Evan Leibovitch, Bruce Perens, Andrew Roach, Bryan Wayne Sparks and Linus Torvalds. Other people on the project were Keith Bostic, Chuck Cranor, Michael Davidson, Chris G. Demetriou, Ulrich Drepper, Don Dugger, Steve Ginzburg, Jon "maddog" Hall, Ron Holt, Jordan Hubbard, Dave Jensen, Kean Johnston, Andrew Josey, Robert Lipe, Bela Lubkin, Tim Marsland, Greg Page, Ronald Joe Record, Tim Ruckle, Joel Silverstein, Chia-pi Tien, and Erik Troan. Operating systems and companies represented were BeOS, BSDI, FreeBSD, Intel, Linux, NetBSD, SCO and SunSoft.

The project progressed and in mid-1998, SCO began developing lxrun, an open-source compatibility layer able to run Linux binaries on OpenServer, UnixWare, and Solaris. SCO announced official support of lxrun at LinuxWorld in March 1999. Sun Microsystems began officially supporting lxrun for Solaris in early 1999, [27] and later moved to integrated support of the Linux binary format via Solaris Containers for Linux Applications.

With the BSDs having long supported Linux binaries (through a compatibility layer) and the main x86 Unix vendors having added support for the format, the project decided that Linux ELF was the format chosen by the industry and "declare[d] itself dissolved" on July 25, 1999. [28]

FatELF: universal binaries for Linux

FatELF is an ELF binary-format extension that adds fat binary capabilities. [29] It is aimed for Linux and other Unix-like operating systems. Additionally to the CPU architecture abstraction (byte order, word size, CPU instruction set etc.), there is the potential advantage of software-platform abstraction e.g., binaries which support multiple kernel ABI versions. As of 2021, FatELF has not been integrated into the mainline Linux kernel. [30] [31] [32]

See also

Related Research Articles

<span class="mw-page-title-main">Minix</span> Unix-like operating system

MINIX is a Unix-like operating system based on a microkernel architecture. Since version 2.0, it has been Portable Operating System Interface (POSIX) compliant.

The Portable Operating System Interface is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. POSIX defines both the system and user-level application programming interfaces (APIs), along with command line shells and utility interfaces, for software compatibility (portability) with variants of Unix and other operating systems. POSIX is also a trademark of the IEEE. POSIX is intended to be used by both application and system developers.

The Single UNIX Specification (SUS) is a standard for computer operating systems, compliance with which is required to qualify for using the "UNIX" trademark. The standard specifies programming interfaces for the C language, a command-line shell, and user commands. The core specifications of the SUS known as Base Specifications are developed and maintained by the Austin Group, which is a joint working group of IEEE, ISO/IEC JTC 1/SC 22/WG 15 and The Open Group. If an operating system is submitted to The Open Group for certification, and passes conformance tests, then it is deemed to be compliant with a UNIX standard such as UNIX 98 or UNIX 03.

<span class="mw-page-title-main">Netwide Assembler</span> Assembler for the Intel x86 architecture

The Netwide Assembler (NASM) is an assembler and disassembler for the Intel x86 architecture. It can be used to write 16-bit, 32-bit (IA-32) and 64-bit (x86-64) programs. It is considered one of the most popular assemblers for Linux and x86 chips.

The Portable Executable (PE) format is a file format for executables, object code, DLLs and others used in 32-bit and 64-bit versions of Windows operating systems, and in UEFI environments. The PE format is a data structure that encapsulates the information necessary for the Windows OS loader to manage the wrapped executable code. This includes dynamic library references for linking, API export and import tables, resource management data and thread-local storage (TLS) data. On NT operating systems, the PE format is used for EXE, DLL, SYS, MUI and other file types. The Unified Extensible Firmware Interface (UEFI) specification states that PE is the standard executable format in EFI environments.

<span class="mw-page-title-main">System call</span> Way for programs to access kernel services

In computing, a system call is the programmatic way in which a computer program requests a service from the operating system on which it is executed. This may include hardware-related services, creation and execution of new processes, and communication with integral kernel services such as process scheduling. System calls provide an essential interface between a process and the operating system.

In computing, tar is a computer software utility for collecting many files into one archive file, often referred to as a tarball, for distribution or backup purposes. The name is derived from "tape archive", as it was originally developed to write data to sequential I/O devices with no file system of their own, such as devices that use magnetic tape. The archive data sets created by tar contain various file system parameters, such as name, timestamps, ownership, file-access permissions, and directory organization. POSIX abandoned tar in favor of pax, yet tar sees continued widespread use.

compress is a Unix shell compression program based on the LZW compression algorithm. Compared to gzip's fastest setting, compress is slightly slower at compression, slightly faster at decompression, and has a significantly lower compression ratio. 1.8 MiB of memory is used to compress the Hutter Prize data, slightly more than gzip's slowest setting.

The archiver, also known simply as ar, is a Unix utility that maintains groups of files as a single archive file. Today, ar is generally used only to create and update static library files that the link editor or linker uses and for generating .deb packages for the Debian family; it can be used to create archives for any purpose, but has been largely replaced by tar for purposes other than static libraries. An implementation of ar is included as one of the GNU Binutils.

A fat binary is a computer executable program or library which has been expanded with code native to multiple instruction sets which can consequently be run on multiple processor types. This results in a file larger than a normal one-architecture binary file, thus the name.

<span class="mw-page-title-main">UNIX System V</span> Early commercial UNIX operating system

Unix System V is one of the first commercial versions of the Unix operating system. It was originally developed by AT&T and first released in 1983. Four major versions of System V were released, numbered 1, 2, 3, and 4. System V Release 4 (SVR4) was commercially the most successful version, being the result of an effort, marketed as Unix System Unification, which solicited the collaboration of the major Unix vendors. It was the source of several common commercial Unix features. System V is sometimes abbreviated to SysV.

Mach-O, short for Mach object file format, is a file format for executables, object code, shared libraries, dynamically loaded code, and core dumps. It was developed to replace the a.out format.

a.out is a file format used in older versions of Unix-like computer operating systems for executables, object code, and, in later systems, shared libraries. This is an abbreviated form of "assembler output", the filename of the output of Ken Thompson's PDP-7 assembler. The term was subsequently applied to the format of the resulting file to contrast with other formats for object code.

In computing, a dynamic linker is the part of an operating system that loads and links the shared libraries needed by an executable when it is executed, by copying the content of libraries from persistent storage to RAM, filling jump tables and relocating pointers. The specific operating system and executable format determine how the dynamic linker functions and how it is implemented.

<span class="mw-page-title-main">Fiwix</span> Operating system

Fiwix is an operating system kernel based on the UNIX architecture and fully focused on being POSIX compatible. It is designed and developed mainly as a hobbyist operating system, but it also serves for educational purposes. It runs on the i386 hardware platform and is compatible with a good base of existing GNU applications. It follows the UNIX System V application binary interface and is also mostly Linux 2.0 system call ABI compatible.

In computing, the System Object Model (SOM) is a proprietary executable file format developed by Hewlett-Packard for its HP-UX and MPE/ix operating systems. In particular, SOM is the native format used for 32-bit application executables, object code, and shared libraries running under the PA-RISC family of processors.

This is a comparison of binary executable file formats which, once loaded by a suitable executable loader, can be directly executed by the CPU rather than being interpreted by software. In addition to the binary application code, the executables may contain headers and tables with relocation and fixup information as well as various kinds of meta data. Among those formats listed, the ones in most common use are PE, ELF, Mach-O and MZ.

<span class="mw-page-title-main">Unix-like</span> Operating system that behaves similarly to Unix, e.g. Linux

A Unix-like operating system is one that behaves in a manner similar to a Unix system, although not necessarily conforming to or being certified to any version of the Single UNIX Specification. A Unix-like application is one that behaves like the corresponding Unix command or shell. Although there are general philosophies for Unix design, there is no technical standard defining the term, and opinions can differ about the degree to which a particular operating system or application is Unix-like.

<span class="mw-page-title-main">Unix</span> Family of computer operating systems

Unix is a family of multitasking, multi-user computer operating systems that derive from the original AT&T Unix, whose development started in 1969 at the Bell Labs research center by Ken Thompson, Dennis Ritchie, and others.

References

  1. 1 2 Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2 (May 1995)
  2. Tool Interface Standard (TIS) Portable Formats Specification Version 1.1 (October 1993)
  3. System V Application Binary Interface Edition 4.1 (1997-03-18)
  4. "Available lexers — Pygments". pygments.org.
  5. "ELF Header". Sco.com. July 2000. Retrieved 2014-02-07.
  6. "LXR linux/include/linux/elf.h". linux.no. Retrieved 27 April 2015.
  7. "glibc 2.12 announce".
  8. "sourceware.org Git - glibc.git/blob - libc-abis".
  9. "sourceware.org Git - glibc.git/blob - sysdeps/gnu/ldsodefs.h". Archived from the original on 2021-03-07. Retrieved 2019-10-28.
  10. "Program Header". Sco.com. July 2000. Retrieved 2017-04-05.
  11. "elfutils". sourceware.org. Retrieved 30 April 2017.
  12. "Binary Formats". Archived from the original on 2019-03-31. Retrieved 2019-03-31.
  13. "MinixReleases – Minix Wiki". Wiki.minix3.org. Archived from the original on 2013-03-30. Retrieved 2014-01-19.
  14. "Archived copy" (PDF). Archived from the original (PDF) on 2020-09-15. Retrieved 2016-10-19.{{cite web}}: CS1 maint: archived copy as title (link)
  15. "GCCSDK – RISC OS". Riscos.info. 2012-04-22. Archived from the original on 2014-02-19. Retrieved 2014-01-19.
  16. "Guardian Programmer's Guide" (PDF). Hewlett Packard Enterprise. Archived from the original (PDF) on 2018-05-30. Retrieved 2018-05-30. p. 44 archived from the original Archived 2018-05-30 at the Wayback Machine on 2018-5-30
  17. Foley, Mary Jo. "Under the hood of Microsoft's Windows Subsystem for Linux | ZDNet". ZDNet. Retrieved 2016-08-19.
  18. PlayStation Portable use encrypted & relocated ELF : PSP
  19. Symbian OS executable file format
  20. Rosen, Kenneth; Host, Douglas; Klee, Rachel; Rosinski, Richard (2007). UNIX: The Complete Reference (2 ed.). McGraw Hill Professional. p. 707. ISBN   9780071706988 . Retrieved 2017-06-08. Dynamically linked libraries are also called shared objects (.so).
  21. Thomas, Romain. "Android formats". Quarks Lab. Archived from the original on 16 Feb 2023. Retrieved 17 Jan 2023.
  22. "Chapter 4: Object Files", System V Application Binary Interface, 2009-10-26, e_machine
  23. "LSB Referenced Specifications". linuxfoundation.org. Retrieved 27 April 2015.
  24. "Executable and Linking Format (ELF)". linuxfoundation.org. Retrieved 27 April 2015.
  25. "Introduction". linuxfoundation.org. Retrieved 27 April 2015.
  26. Leibovitch, Evan (1997-12-23). "86Open Frequently-Asked Questions". Archived from the original on 2007-03-11. Retrieved 2007-06-06.
  27. Record, Ronald (1998-05-21). "Bulletin on status of 86open at SCO". Archived from the original on 2008-12-08. Retrieved 2008-05-06.
  28. Leibovitch, Evan (1999-07-25). "The86open Project – Final Update". Archived from the original on 2007-02-27. Retrieved 2007-05-06.
  29. Gordon, Ryan. "fatelf-specification v1". icculus.org. Retrieved 2010-07-25.
  30. Gordon, Ryan. "FatELF: Turns out I liked the uncertainty better". icculus.org. Retrieved 2010-07-13.
  31. Holwerda, Thom (2009-11-03). "Ryan Gordon Halts FatELF Project". osnews.com. Retrieved 2010-07-05.
  32. Brockmeier, Joe (June 23, 2010). "SELF: Anatomy of an (alleged) failure". Linux Weekly News. Retrieved 2011-02-06.

Further reading