Object files — .o - .obj, symbol table, relocation entries: Worked examples

You have met the relocation formula on the parent note:

This page does one thing: it throws every kind of case at that formula so you never meet a scenario in the wild you haven't already solved on paper.

The scenario matrix

Think of a relocation as having a few "knobs". Each knob has a small set of settings. The matrix below lists every setting we must cover, and which worked example nails it.

#	Case class	The knob's settings	Covered by
A	Reloc kind	absolute ( $S + A$ ) vs PC-relative ( $S + A - P$ )	Ex 1, Ex 2
B	Displacement sign	forward jump ( $V > 0$ ) vs backward jump ( $V < 0$ )	Ex 2, Ex 3
C	Addend	zero addend vs non-zero ( $- 4$ )	Ex 1, Ex 2
D	Symbol binding	DEFINED here vs UND (undefined, needs another `.o`)	Ex 1, Ex 4
E	Degenerate distance	$S = P$ (patch points at itself)	Ex 5
F	Zero-size input	`.bss` symbol — takes no file bytes	Ex 6
G	Overflow / limit	displacement doesn't fit in 32 bits	Ex 7
H	Word problem	real linker command, real `readelf` reading	Ex 8
I	Exam twist	two definitions of one symbol (multiple-definition)	Ex 9

For the picture-based examples we'll use one number line: memory addresses increasing to the right. See it once:

Ex 1 — Absolute reloc, zero addend (cells A, C, D-defined)

Worked example

A global pointer stores the address of a global variable, both defined in this file:

int g;          // ends up in .bss
int *p = &g;    // ends up in .data, must contain &g

After linking, the linker places g at address 0x4020. What 8 bytes get written into p? The reloc is R_X86_64_64 (absolute, 64-bit), addend 0.

Forecast: guess before reading — will the bytes be g's address, or a distance? (Absolute → the address itself.)

Identify the knobs. Why this step? Every relocation is solved by first reading $S$ , $A$ , $P$ off the entry. Here $S = 0x4020$ , $A = 0$ , and because it's absolute we don't need $P$ .
Pick the formula: absolute ⇒ $V = S + A$ . Why this step? The bytes of p must hold the actual address of g so the running program can dereference it. A distance would be meaningless for a data pointer.
Compute: $V = 0x4020 + 0 = 0x4020$ . Why this step? Just the arithmetic; the addend is 0 because &g has no +offset.

Verify: $0x4020 = 16416$ . Plugging back, $16416 + 0 = 16416$ ✓. Units: an address, correct for a pointer.

Ex 2 — PC-relative forward call, addend $- 4$ (cells A, B-forward, C-nonzero, D-UND)

Worked example

main.c calls an external function:

extern int add(int,int);
int main(){ return add(2,3); }

The call instruction's 4-byte displacement slot sits at $P = 0x1010$ . After linking, add lands at $S = 0x1040$ . Reloc type R_X86_64_PLT32, addend $A = - 4$ . What 4 bytes get written?

Forecast: add is ahead of the call — so is the displacement positive or negative?

Read knobs: $S = 0x1040$ , $P = 0x1010$ , $A = - 4$ . Why this step? PC-relative needs all three; $P$ is the slot itself, not the next instruction.
Formula: PC-relative ⇒ $V = S + A - P$ . Why this step? The CPU computes the branch target as (address of next instruction) $+$ displacement. The $- 4$ addend soaks up the 4 displacement bytes between $P$ and that next instruction, so the jump lands exactly on add.
Compute in decimal: $S = 4160$ , $P = 4112$ . $V = 4160 + (- 4) - 4112 = 44$ . Why this step? $44 = 0x2C$ , a small positive displacement — forward, matching our forecast.

Verify: next-instruction address $= P + 4 = 4116$ . Target $= 4116 + V = 4116 + 44 = 4160 = 0x1040 = S$ ✓. Lands exactly on add.

Ex 3 — PC-relative backward call (cell B-backward)

Forecast: target is below $P$ in memory → expect a negative displacement.

Knobs: $S = 7936$ , $P = 8192$ , $A = - 4$ . Why this step? Same PC-relative case; only the numbers moved.
$V = S + A - P = 7936 - 4 - 8192 = - 260$ . Why this step? Negative, as forecast — the CPU jumps backwards.
Interpret the bytes: the field is a signed 32-bit integer; $- 260$ is stored two's-complement as 0xFFFFFEFC. Why this step? Machine code never stores a minus sign; negativity lives in the top bit.

Verify: next instruction $= 8192 + 4 = 8196$ . Target $= 8196 + (- 260) = 7936 = 0x1F00 = S$ ✓.

Ex 4 — Undefined symbol that is never resolved (cell D-UND, error path)

Worked example

main.c references add (UND), but we forget to link add.o:

$ gcc main.o        # no add.o!

What happens, and why is it a linker error, not a compiler error?

Forecast: does this fail at compile or at link time?

Compiling main.c alone succeeds — add was declared (extern), so the compiler is happy. Why this step? The compiler only checks types & declarations, not existence of the definition.
The .o carries a symbol-table entry add marked UND, plus a relocation waiting for its address. Why this step? This is the "I am looking for add" badge from the parent note.
The linker scans every input for a DEFINED add. Finding none, it cannot compute $S$ , so it cannot apply $V = S + A - P$ . Why this step? No $S$ ⇒ no arithmetic possible ⇒ hard stop.
Result: undefined reference to 'add'. Why this step? This is a link error; adding a #include would not help — you must supply the defining .o/library. See Linker — symbol resolution and relocation.

Verify: the fix is gcc main.o add.o. Conceptually: number of unresolved UND symbols must reach $0$ before an executable is produced. Here it was $1$ , so failure. ✓ (see Static vs Dynamic Linking for how a shared lib supplies $S$ later instead.)

Ex 5 — Degenerate case: symbol patches itself, $S = P$ (cell E)

Forecast: if "here" equals "there", is the displacement zero?

Knobs: $S = P = 12288$ , $A = - 4$ . Why this step? Set up the degenerate values.
$V = S + A - P = 12288 - 4 - 12288 = - 4$ . Why this step? The $S$ and $P$ cancel; only the addend survives.
Read it: $V = - 4$ means "jump to 4 bytes before the next instruction" — i.e. back to the start of this instruction's operand. Why this step? Shows the addend is doing real geometric work even when $S = P$ ; it's never just decoration.

Verify: next instruction $= P + 4 = 12292$ . Target $= 12292 + (- 4) = 12288 = S$ ✓. Even in the degenerate case the formula lands on $S$ exactly.

Ex 6 — Zero-size file input: `.bss` (cell F)

Forecast: guess the on-disk byte count for a million ints.

big is uninitialised ⇒ goes to .bss. Why this step? .bss is the zero-init section; it stores a size, not the zeros themselves (see Sections — .text .data .bss .rodata).
File cost $= 0$ bytes. The symbol records size $= 1, 000, 000 \times 4 = 4, 000, 000$ bytes. Why this step? The loader zero-fills at run time, so the disk image stays tiny.
Any pointer to big still needs an absolute reloc ( $V = S + A$ ) once the loader assigns its address. Why this step? Zero file bytes doesn't mean zero relocations — the address is still unknown at compile time.

Verify: if this were .data, file would grow by $4, 000, 000$ bytes. In .bss it grows by $0$ . Savings $= 4, 000, 000 - 0 = 4, 000, 000$ bytes ✓.

Ex 7 — Limiting case: displacement overflow (cell G)

Forecast: does a 3-gigabyte forward jump fit in 32 signed bits?

Max positive displacement $= 2^{31} - 1 = 2147483647 \approx 2.15 \times 1 0^{9}$ . Why this step? Establishes the ceiling of a signed 32-bit slot.
Required $V \approx 3 \times 1 0^{9} > 2.15 \times 1 0^{9}$ . Why this step? Compare need vs capacity — the number cannot be represented.
The linker emits relocation truncated to fit: R_X86_64_PC32. Why this step? Writing the number would silently corrupt the top bits, so the linker refuses. Fix: compile with a larger code model (or use R_X86_64_64 absolute / a GOT/PLT indirection).

Verify: $3 \times 1 0^{9} > 2^{31} - 1 = 2147483647$ ⇒ overflow ✓. And $3 \times 1 0^{9} < 2^{63} - 1$ , so a 64-bit absolute reloc would fit. ✓

Ex 8 — Word problem: reading a real `readelf -r` line (cell H)

Worked example

readelf -r main.o prints (simplified):

Offset      Type            Sym.Value   Sym.Name + Addend
000000000011 R_X86_64_PLT32  0000000000  add - 4

The linker will place .text at base 0x1000, and add at 0x1040. What byte value ends up in the slot at file offset 0x11?

Forecast: which of Ex 1–7 does this reduce to?

Compute the slot's final address $P$ : base $+$ offset $= 0x1000 + 0x11 = 0x1011$ . Why this step? The reloc's Offset is within the section; $P$ needs the section's final placement added.
Read $A = - 4$ (from add - 4), $S = 0x1040$ . Why this step? These are the other two knobs, straight off the line.
It's R_X86_64_PLT32 ⇒ PC-relative ⇒ $V = S + A - P$ . Why this step? Same case as Ex 2, now driven by real tool output.
Compute: $S = 4160$ , $P = 0x1011 = 4113$ . $V = 4160 - 4 - 4113 = 43 = 0x2B$ . Why this step? Final answer, the byte value (little-endian: 2B 00 00 00).

Verify: next instr $= P + 4 = 4117$ ; target $= 4117 + 43 = 4160 = 0x1040 = S$ ✓.

Ex 9 — Exam twist: two definitions of one symbol (cell I)

Forecast: two globals, same name — merge, error, or silent bug?

Each compiler sees only its own file, so each emits a GLOBAL tentative definition symbol x. Neither compilation fails. Why this step? The compiler has no cross-file view; uniqueness of globals is the linker's job (see Name mangling in C++ for how C++ makes symbol names unique, unlike C).
At link, the linker finds two DEFINED x with GLOBAL binding. Why this step? Each "I can provide x" badge must be unique; two providers is a conflict.
Outcome depends on the era: modern GCC (-fno-common) ⇒ multiple definition of 'x' error; legacy common-symbol behaviour ⇒ silently merges into one x (a classic aliasing bug). Why this step? Shows both the safe error and the dangerous silent path.
Fix: static int x; (file-local, becomes a LOCAL symbol) or one definition int x; plus extern int x; elsewhere. Why this step? Restores the "exactly one provider" invariant.

Verify: count of GLOBAL DEFINED x symbols must be $\leq 1$ for a clean link. Two files ⇒ count $= 2 > 1$ ⇒ conflict ✓.

Recall Which formula for each reloc kind?

Absolute (R_X86_64_64) uses ::: $V = S + A$ PC-relative (R_X86_64_PC32 / PLT32) uses ::: $V = S + A - P$ Why the $- P$ in PC-relative? ::: the CPU adds the stored value to the next instruction's address, so the linker must store a distance from here, not an absolute address.

Recall Sign & overflow sanity

A forward jump gives displacement of what sign? ::: positive A backward jump gives what sign? ::: negative A 4-byte PC32 field holds what range? ::: signed 32-bit, $[- 2^{31}, 2^{31} - 1]$ ; beyond it the linker says "relocation truncated to fit"