Why Hard-Coding Memory Addresses Is a Nightmare and How Symbols Solve It

The problem with absolute addresses

In early programming, developers often hard‑code the absolute memory address of a function, e.g. call 0x1234. When the function moves, every call must be updated, which is tedious and error‑prone.

Introducing symbols

Instead of using raw addresses, a function can be referenced by a symbolic name such as add. The assembler records the name, and the linker later replaces it with the correct address.

Object files, symbol tables and relocation tables

When a source file is compiled, the compiler produces an object file (".obj" or ".o") that contains:

Machine code with placeholders where external symbols are called.

A symbol table that lists the symbols defined in the module and their offsets.

A relocation table that marks each placeholder that needs to be patched during linking.

Example object‑file dump (simplified):

-- main.obj --
代码段:
  偏移 0x03: mov dx, 20
  偏移 0x06: call ???  (需要重定位，调用 add)
符号表:
  start -> 偏移 0x00
未解析引用:
  add (外部符号)

Linking: resolving symbols and applying relocations

The linker performs two main steps:

Symbol resolution : it builds a global symbol dictionary from all object files, matches each undefined reference with a definition, and reports conflicts or missing symbols.

Relocation : it decides the final layout of each module in memory, computes the absolute address of every symbol, and patches the placeholders recorded in the relocation tables.

If every reference is resolved, the final executable contains only concrete addresses; otherwise the linker emits an “undefined reference to …” error.

Benefits of using symbols and a linker

Reduces human error by eliminating manual address calculations.

Simplifies maintenance: adding or moving functions does not require editing call sites.

Enables modular compilation: each module can be compiled independently.

Provides a clear data structure (symbol and relocation tables) for automated linking.