The ELF object file format is adopted by many UNIX-like operatingsystems. Understanding its specifications can be an interestingjourney.
The format consists of the generic specification, processor-specificspecifications, and OS-specific specifications. Three key documentsoften surface when searching for the generic specification:
The TIS specification breaks ELF into the generic specification, aprocessor-specific specification (x86), and an OS-specific specification(System V Release 4). However, it has not been updated since 1995. TheSolaris guide, though well-written, includes Solaris-specific extensionsnot applicable to Linux and *BSD. This leaves us primarily with theSystem V ABI hosted on www.sco.com, which dedicates Chapters 4 and 5 tothe ELF format.
Let's trace the ELF history to understand its relationship with theSystem V ABI.
Unix System Laboratories (USL) created ELF for their System V Release4 in 1980s. USL also maintained the System V Application BinaryInterface, of which ELF was a core component. USL intended ELF to be anopen standard and published documents about the format, e.g.
In 1993, the Tool Interface Standard (TIS) Committee, a consortium ofindustry leaders, adopted ELF and developed the "Tool Interface Standard(TIS) Portable Formats Specification". Version 1.2 was released in May1995.
ELF has been very influential. In the 1990s, many Unix and Unix-likeoperating systems, including Solaris, IRIX, HP-UX, Linux, and FreeBSD,switched to ELF. The 86open Project's FAQ specified:
Q18: How can you get a single binary to work identically across allthese diverse systems?
Most Unix-on-Intel binary packages are already largely similar.Almost all such operating systems use the "ELF" binary 'packaging'; thevarious operating systems have small but significant differences,though, that make each system's ELF binary unusable on others'.
The Tool Interface Standard (TIS) Committee essentially dissolvedafter 1995. The stewardship of the System V ABI, and consequently thegeneric ELF specification, has followed a complex path mirroring thetransfer of Unix software assets.
Between 1993 and 2011, Unix assets underwent a few transfers.
The task of maintaining and updating the generic ABI fell tothese successive owners of Unix software assets. The Santa CruzOperation, and later The SCO Group and Xinuos, managed updates andextensions to the ABI, including the ELF specification.
In this binutilscommit in November 2000, it was said that e_machinevalues should eventually ask registry@sco.com forblessing.
Dave Prosser had maintainedthe System V ABI at USL, The Santa Cruz Operation, and the SCO Group.The last maintainer at The SCO Group and UnXis/Xinuous was John Wolfe,who oversaw updates until his departurefrom Xinuos in 2015. The generic ABI (including the ELFspecification) then became unmaintained.
The final functional update on https://www.sco.com/developers/gabi/latest/contents.htmlwas made in June 2013 forSHF_COMPRESSED. Since then, the specification hasremained frozen.
The copyright notices on the SCO website's documentation for theSystem V ABI seem potentially misleading.
The footnotes of https://www.sco.com/developers/gabi/1998-04-29/contents.htmlpages today (and in 2003 per web.archive.org) specify:
© 1997, 1998, 1998 The Santa Cruz Operation, Inc. All rightsreserved.
The footnotes of https://www.sco.com/developers/gabi/latest/contents.htmlpages specify:
© 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc. Allrights reserved. © 2002 Caldera International. All rights reserved. ©2003-2010 The SCO Group. All rights reserved. © 2011-2015 Xinuos Inc.All rights reserved.
The repeated phrase "All rights reserved" could be interpreted asimplying exclusive ownership over the ELF format itself. This isinaccurate, as ELF is an open standard developed through thecollaboration of many organizations and individuals.
The earliest available snapshot on the Wayback Machine dates back to2003, a time when The SCO Group had assumed ownership and initiated alawsuit against IBM, alleging that the success of Linux was due to themisappropriation of SCO's technology. Regrettably, earlier snapshots areunavailable to provide a more complete historical context.
Further reading:
A neutral GoogleGroup not affliated with The SCO Group/Xinuous exists for discussingthe generic ABI. Hongjiu Lu might be the owner. The group served as aplatform for OS and toolchain vendors to collaborate. In recent years,participation has dwindled to primarily representatives from OracleSolaris (just Ali Bahrami) and the GNU toolchain.
The reduced activity might not seem critical, as significantnon-OS-specific changes to the ELF format are infrequent.
https://www.sco.com/developers/gabi/latest/revision.htmloutlines the evolution of the ELF from 1998 to 2013. Important featureswere all available as of April 2001.
EI_OSABI and EI_ABIVERSIONSHF_MERGEand SHF_STRINGSSHF_LINK_ORDERHowever, discussions regarding these specific features seemunavailable. Please let me know if you have any information onthem.
There were merely constant updates from April 2001 to June 2013.SHF_COMPRESSED was added in June 2013.
The generic-abi Google Group reached consensus onproposals that haven't been reflected on the www.sco.comwebsite:
ELFCOMPRESS_ZSTDIn April 2020, Cary Coutant reached a preliminaryagreement with Xinuos, but the future remainsuncertain. While some constants (e.g., e_machineand EI_OSABI values, ELFCOMPRESS_ZSTD) havebeen defined, no functional updates to the ABI have materialized.
The absence of a centralized, up-to-date repository for thespecification complicates matters. While some clarificationsand consensus have been reached within the generic-abi group, accessingthe latest, definitive text remains a challenge.
A potential solution could be to decouple the ELFspecification from the broader System V ABI, as was done in thepast with the TIS specification. This would create a dedicated andaccessible reference for ELF, independent of the broader System Vspecificities that are of less general interest.
Despite this uncertainty, innovation within the ELF ecosystem shouldcontinue. Efforts like my own to replace ELF control structures toreduce object file sizes (e.g., compactrelocations.) can still move forward. In practice, achievingconsensus among major toolchain vendors and prioritizing stability maybe sufficient, even without formal approval from the generic ABI. Whilealigning with Solaris would be ideal and I will try doing so, this mightnot always be feasible due to varying priorities.
FreeBSD, which Xinuos's OpenServer is based on, utilizes the LLVMtoolchain. Xinuos might indirectly benefit from my heavy involvementinto the LLVM toolchain.
Processor-specific details for the System V ABI are found in thepsABI documents. Actively maintained psABIs exist for variousarchitectures including AArch32, AArch64, LoongArch, PPC64, RISC-V,s390x, i386, and x86-64.
For MIPS, the most recent o32 ABI dates back to February 1996, andthe n64 ABI is unavailable.
Interestingly, for 16-bit address architectures like Motorola 6800,the ELFCLASS32 format is employed.
In the System V ABI, Operating System Specific ABIs (OSABI) areextensions that provide operating system-specific details to supplementthe generic ABI.
For example, Oracle Solaris Linkers and Libraries Guidedefines the OSABI for Solaris.
The Linux OSABI is composed of multiple elements, including:
Until the recent introduction of gABI supplement for programloading and dynamic linking on GNU, SHT_GNU_HASH,while widely adopted, was absent from any official documentation.
The Linux Standard Base (LSB) is a related document that aims tostandardize the Linux system interface.