Linkers and Loaders: ELF, PE, and Mach-O Deep Dive

When you compile a C++ program, the compiler produces object files (.o on Linux, .obj on Windows). These contain machine code but with placeholders for symbols defined in other files. The linker's job is to resolve these symbols, assign final addresses, and produce an executable. The loader then loads that executable into memory and starts it.

Understanding linkers and loaders is crucial for debugging cryptic errors like 'undefined reference', 'segmentation fault', or 'library not loaded'. This article dives into the three major executable formats: ELF (Linux), PE (Windows), and Mach-O (macOS). We'll explore their structures, symbol resolution, relocation, and dynamic linking. You'll learn how to inspect binaries, diagnose linking issues, and apply best practices in production.

Real-world incidents often stem from subtle linking problems: mismatched calling conventions, symbol visibility, or library versioning. By the end, you'll be equipped to handle these challenges with confidence.

Executable Formats Overview

Executable formats define how code and data are organized in a binary file. The three major formats are ELF (Executable and Linkable Format) used on Linux and Unix-like systems, PE (Portable Executable) used on Windows, and Mach-O (Mach Object) used on macOS and iOS. Each format has its own header structures, section organization, and dynamic linking mechanisms.

ELF is the most flexible, supporting multiple architectures and advanced features like thread-local storage. PE is derived from COFF and includes a DOS stub for backward compatibility. Mach-O is designed for the Mach kernel and uses a two-level namespace for symbols.

Understanding these formats helps when debugging issues like 'file not recognized' or 'bad executable' errors. Tools like 'file' can identify the format: 'file myprogram' might output 'ELF 64-bit LSB executable, x86-64'.

file myprogram
# Output: myprogram: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=..., not stripped

ELF File Structure

An ELF file begins with an ELF header that contains magic number (\x7fELF), class (32/64-bit), endianness, OS/ABI, and entry point. Following the header are program headers (for loading) and section headers (for linking).

Dynamic linking uses .dynamic, .dynsym, .dynstr, .got, and .plt sections. The Global Offset Table (GOT) and Procedure Linkage Table (PLT) enable position-independent code.

Example: Inspecting ELF sections with readelf.

#include <iostream>
int global_var = 42;
int uninit_var;
const int const_var = 100;
int main() {
    static int static_var = 0;
    std::cout << "Hello, ELF!" << std::endl;
    return 0;
}

PE File Structure

PE files start with a DOS header (MZ) and a DOS stub, followed by the PE signature and COFF header. The optional header contains image base, entry point, and data directories. Sections include .text, .data, .rdata, .idata (import), .edata (export), and .reloc (base relocations).

PE uses Import Address Table (IAT) and Export Address Table (EAT) for dynamic linking. The loader resolves imports by walking the IAT and patching addresses.

Example: Dumping PE headers with dumpbin.

dumpbin /headers myprogram.exe
# Output includes DOS header, PE signature, COFF header, optional header, and section headers.

Mach-O File Structure

Mach-O files have a header with magic (MH_MAGIC_64), followed by load commands that describe segments and sections. Segments include __TEXT (code), __DATA (data), __LINKEDIT (symbols, strings).

Mach-O uses two-level namespace for symbols: each symbol is associated with its defining library. This avoids symbol clashes but can cause 'symbol not found' errors if libraries are missing.

Example: Using otool to inspect Mach-O.

otool -L myprogram
# Output: myprogram:
#   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
#   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

Symbol Resolution and Relocation

Symbol resolution is the process of matching symbol references to definitions across object files. Relocation adjusts addresses in code and data to reflect the final memory layout.

There are two types of relocation: static (at link time) and dynamic (at load time). Static relocation modifies the binary directly; dynamic relocation uses GOT/PLT.

Example: A simple C++ program with external symbol.

// file1.cpp
int foo();
int main() { return foo(); }

// file2.cpp
int foo() { return 42; }

Dynamic Linking and Loading

Dynamic linking allows executables to use shared libraries at runtime. The dynamic linker/loader (ld.so on Linux, dyld on macOS, Ldr on Windows) resolves symbols and loads libraries.

On Linux, the dynamic linker uses LD_LIBRARY_PATH, rpath, and ldconfig cache. On macOS, dyld uses DYLD_LIBRARY_PATH and install names. On Windows, the loader searches the application directory, system directories, and PATH.

Example: Setting rpath during linking.

g++ -o myprogram main.cpp -L. -lmylib -Wl,-rpath,'$ORIGIN/lib'
# This sets rpath to a 'lib' subdirectory relative to the executable.
# $ORIGIN expands to the directory containing the executable.

Best Practices and Debugging Tools

Example: Using version script to hide internal symbols.

{
    global:
        public_function;
    local:
        *;
};