Linking and Loading

After the compiler outputs .o files, linking and loading are still needed before execution—relocation turns symbol references into addresses, PLT/GOT lazy binding resolves dynamic libraries only on the first call, and LTO defers cross-module optimization to link time for whole-program analysis.

Overview

After the compiler outputs .o (object files), two more steps are needed to produce a "runnable executable": linking (resolving symbol references from multiple .o files and libraries into addresses) and loading (mapping the executable into the process address space and jumping to the entry point after initialization). The linker does more than just "concatenating"—it performs relocation, garbage-collects unreferenced sections, and performs LTO (whole-program optimization across compilation units). This article follows the chain from "compiler output → static linking → dynamic linking → dynamic loading" to explain every layer of linking and loading mechanisms.

Compiler Output: Object Files (ELF)

A .o file (in ELF format) contains:

- .text:   Machine code (code segment)
- .data:   Initialized global variables
- .bss:    Uninitialized (or zero-initialized) global variables — does not occupy file space; the OS maps zero pages during loading
- .rodata: Read-only data (string literals, floating-point constants)
- .symtab: Symbol table (symbols exported/imported by this file)
- .rela.text: Relocation table for the text section (which instructions reference external symbols and need patching by the linker)
- .rela.data: Relocation table for the data section
- .debug_info, .debug_line, ...: DWARF debug information

The final step of the compiler (the assembler) outputs .o. The linker reads the symbol tables of all .o files and libraries, performs relocations, and produces the executable.

Relocation: From "Symbol References" to "Addresses"

In the machine code of .o files, references to external symbols are filled with 0 or placeholders. .rela.text records these locations:

Typical relocation entry (R_X86_64_PC32):
  Offset: 0x42    ← Location in .text that needs patching
  Symbol: printf  ← Which symbol is referenced
  Type: R_X86_64_PC32  ← Relative jump (PC + offset)
  Addend: -4      ← Compensation (PC in the instruction points to the next instruction, a difference of 4 bytes)

After assigning load addresses to all sections, the linker iterates through all relocation entries, calculates the final address of the target symbol, and rewrites the bytes at the target location according to the type-specific formula:

R_X86_64_PC32 patching formula:   *(target) = sym_addr - (target_addr + 4) + addend
R_X86_64_64   patching formula:   *(target) = sym_addr + addend        (absolute address)

Static Linking: .a (archive)

A static library is a bundle of .o files (in ar format), extracted on demand during linking:

gcc main.o -L. -lmylib → The linker does:
  1. Collect unresolved symbols from main.o
  2. Search for each unresolved symbol in libmylib.a
  3. If found → extract the corresponding .o from .a and add it to the link set
  4. Extracted .o may introduce new unresolved symbols → recursive (or multi-pass scan)
  5. All symbols resolved → perform relocation → output executable

The linker's symbol resolution is order-sensitive—traditional Unix linkers process .o and .a files from left to right. If libfoo.a is placed before the .o that references it, it might not be scanned (because there are no unresolved symbols requiring its symbols at that point). Modern linkers (LLD) provide --start-group / --end-group for iterative scanning to eliminate order issues.

Linker GC (dead section elimination)

Compilers generate .text section fragments on a per-function basis (gold and LLD support --gc-sections). The linker starts from the entry point (_start), traces call/jump references, marks unreferenced function sections as dead, and discards them. This reduces the final binary size—similar to DCE but across .o units.

Dynamic Linking: .so (shared object)

Dynamic libraries are not copied into the executable at link time; instead, dependencies are recorded at link time and loaded and dynamically resolved at runtime.

GOT and PLT: Two Layers of Lazy Binding

Target Code and ABI mentioned that PIC requires GOT. The complete picture for dynamic linking is GOT + PLT:

First call to printf (slow path: goes through dynamic linker resolution) call printf@plt (PLT stub) → Check GOT[printf] (unresolved) jmp _dl_runtime_resolve Dynamic linker searches symbol table → finds address Update GOT[printf] = Real address → jmp printf

Nth call (hit path: GOT already has real address) call printf@plt Same PLT stub GOT[printf] already has real address → jmp printf, no extra overhead

void *handle = dlopen("libplugin.so", RTLD_NOW);
void (*fn)(int) = dlsym(handle, "plugin_init");
fn(42);
dlclose(handle);