COFF

COFF
Name	COFF
Full name	Common Object File Format
Introduced	1983
Developer	AT&T Corporation
Type	Object file format
Extension	.o, .obj
Magic	architecture-dependent
Owner	UNIX System Laboratories
Open	Yes (specification published)

COFF

COFF is the Common Object File Format, a binary object file format introduced in the early 1980s for use on UNIX System V systems and related commercial UNIX derivatives. It provided a structured way to represent compiled code, data, symbol tables, and relocation information for linkers and loaders used by toolchains such as those from AT&T Corporation, Sun Microsystems, DEC, and later vendors. COFF influenced and competed with other formats adopted by companies including IBM, Microsoft, and projects like BSD and GNU Project.

History

COFF was developed by AT&T Corporation engineers as part of the development of UNIX System V and was formalized in documentation circulated with early System V releases. It followed and replaced ad hoc formats used on Bell Labs research systems and contemporaneous implementations at University of California, Berkeley that produced the a.out format. Over time, COFF was adopted by commercial vendors such as Sun Microsystems for SunOS, Hewlett-Packard for early RISC systems, and Digital Equipment Corporation for VAX and MIPS support. Criticisms of COFF's limitations prompted extensions and alternative designs; notable responses included the Extended COFF (XCOFF) used by IBM on AIX and Microsoft's development of the Portable Executable format for Windows NT. The GNU Project and BSD communities eventually converged on the Executable and Linkable Format developed by Unix International and others, which addressed many COFF shortcomings.

File format and structure

A COFF file organizes information into headers, sections, symbol tables, and relocation entries so that linkers and loaders can resolve addresses and compose executables. The primary COFF header (file header) contains fields such as machine type (identifying architectures like Intel 80386, MIPS, SPARC), number of sections, timestamp, and pointers to the symbol table. Following the file header are section headers describing segments such as text, data, and bss; each section header records size, file offset, and section flags used by linkers in systems like SunOS and AIX. Symbol tables store entries for global and local symbols, identifying names associated with addresses and storage classes; relocation entries list places within sections that need adjustment when symbols are resolved by linkers such as those in GCC toolchains or proprietary compilers from Microsoft.

COFF's representation supports both absolute and relative relocations and allows for storage of auxiliary symbol information used by debuggers like dbx and GDB. However, earlier COFF versions had fixed-size fields for section and symbol counts and limited support for debugging metadata, which affected integration with debuggers from SGI, Sun Microsystems, and other vendors. The lack of standardized extension mechanisms led vendors to create incompatible variants that embedded vendor-specific tables or alternate header interpretations.

Variants and implementations

Multiple vendors extended COFF to meet platform-specific needs. IBM developed XCOFF for AIX to accommodate large symbol tables, richer debugging information, and processor-specific flags; XCOFF later added features used by systems like POWER and RS/6000. Microsoft adapted COFF concepts into the Microsoft COFF for early MS-DOS and Windows NT toolchains, ultimately evolving into the Portable Executable format used across the Windows family. DEC created COFF-like layouts for VAX and Alpha toolchains, integrating with toolsets such as Compaq compilers. Open-source projects implemented COFF readers and writers in utilities like binutils and linking tools used by the GNU Project and LLVM; these implementations often handle multiple COFF dialects and vendor extensions.

Tooling and compatibility

Toolchains such as GCC, Clang (compiler), and MSVC interact with COFF or its variants through assemblers, linkers, and debuggers. The GNU binutils suite provides objdump, readelf equivalents, and ld support for COFF variants, while LLVM's lld and llvm-objdump offer alternative implementations. Debuggers including GDB and vendor tools from IBM and Microsoft parse COFF symbol tables and relocation metadata to provide source-level debugging. Linkers on platforms like AIX and Windows include COFF-compatible loaders; compatibility layers such as Cygwin and MinGW bridge between UNIX-style toolchains and Windows COFF-based executables. Interoperability challenges arise from differences in section naming, relocation types, and symbol storage conventions employed by vendors like Sun Microsystems, HP, and IBM.

Comparison with other object file formats

COFF is often compared with formats that emerged to address its limitations. The a.out format, used historically on BSD systems and early UNIX implementations, is simpler but less flexible for complex object linking than COFF. The Executable and Linkable Format (ELF), developed by a consortium including UNIX International and adopted by Linux, FreeBSD, and NetBSD, provides extensible headers, richer section and segment models, and standardized debugging sections compatible with tools like GDB and binutils; ELF was explicitly designed to overcome COFF restrictions. Microsoft's Portable Executable format, while sharing COFF heritage, integrates with Windows loader semantics and the PE/COFF conventions used by Visual Studio and Windows NT subsystems. IBM's XCOFF offers richer metadata for AIX but remains vendor-specific compared with the cross-platform adoption of ELF. In modern build ecosystems involving GCC, Clang (compiler), LLVM, GNU Project, and platform SDKs from Microsoft, COFF survives primarily as a historical foundation and as the basis for Windows-compatible object files rather than as the dominant cross-platform standard.

Category:Object file formats