How Linkers Assign Virtual Addresses Before Your Program Runs

Virtual Address Space

Modern operating systems give each process its own private, continuous virtual address space ranging from 0 up to the maximum address (e.g., 0xFFFFFFFF on 32‑bit systems). The process sees this space as if it owned the entire memory, allowing a stable and consistent view of code and data.

Because the layout of the virtual address space is stable for the lifetime of the process, the linker can rely on it when assigning addresses.

ABI and Executable File Format Conventions

Operating systems also define a default load base address (e.g., 0x400000 for ELF on Linux). When merging object files, the linker follows a linker script that specifies the order of sections, each section’s starting virtual memory address (VMA), and alignment constraints.

SECTIONS {
    . = 0x400000;       /* base address */
    .text : { *(.text) } /* .text follows base */
    . = ALIGN(4096);    /* 4 KB alignment */
    .data : { *(.data) } /* .data after .text */
    .bss  : { *(.bss) }  /* .bss at the end */
}

Order of sections such as .text, .data, .bss, .rodata.

Starting VMA for each section.

Alignment rules (e.g., ALIGN(4096)).

The linker uses the script to compute the final virtual addresses of all code and data, which are recorded in the ELF file.

From Virtual to Reality

At runtime, the loader maps the ELF into the process’s virtual address space, and the operating system later maps those virtual pages to physical memory on demand. The program never needs to know its actual physical address.

This division of responsibilities—linker, OS, and hardware (MMU)—allows the system to determine a program’s memory layout before execution, illustrating the power of abstraction in modern computing.