Linker Scripts, Sections, and Memory Maps

Author: Marcos Azevedo

Date: 2026-01-20

Last Modified: 2026-01-20

Reading Time: 4 mins

Section: Series

Categories: series

Tags: c-lang programming risc-v

TL;DR

You’ll learn what the linker really does: it places code/data into addresses according to rules and produces an ELF where virtual addresses match the target memory map.
You’ll learn how .text, .rodata, .data, .bss, and startup code relate to VMA (Virtual Memory Address) and LMA (Load Memory Address).
You’ll write a linker script for a small bare-metal RV32 program, generate a link map (.map), and convert the ELF into a raw .bin.

Important

Firmware work is linker-script work. If you can’t reason about sections and placement, you can’t reliably reason about “where in memory” something lives.

1. The linker’s job (a practical definition)

Given:

object files (.o) containing sections and relocations,
libraries (optional),
a memory layout,

The linker produces:

an executable ELF with final addresses,
resolved symbols,
and (optionally) a map file that explains every placement decision.

2. Sections you must know

Section	Meaning	File bytes?	Memory bytes?
`.text`	code	yes	yes
`.rodata`	read-only constants	yes	yes
`.data`	initialized globals	yes	yes
`.bss`	zero-initialized globals	no	yes

Note

.bss has no bytes in the file because it’s represented as “allocate N bytes and fill with zeros”.

3. VMA vs LMA (why there can be two addresses)

VMA (Virtual Memory Address): where the bytes live when the program runs.
LMA (Load Memory Address): where the bytes are stored in the image that loads them.

In bare-metal firmware, a common pattern is:

code runs from RAM,
but .data is stored in flash and copied into RAM at boot.

That implies:

.data VMA is in RAM,
.data LMA is in flash.

We’ll use a simpler single-region RAM layout first, then explain the “copy down” idea.

4. Hands-on: a bare-metal RV32 program with explicit placement

Create:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
// src/ld_demo.c
#include "types.h"

volatile u32 g_counter = 0u;      // .bss or .data depending on init
volatile u32 g_init    = 0x1234u; // .data

void _start(void) {
  for (;;) {
    g_counter++;
    g_init ^= 0x1111u;
  }
}

Create a linker script:

/* src/ld_demo.ld */
OUTPUT_ARCH(riscv)
ENTRY(_start)

MEMORY {
  RAM (rwx) : ORIGIN = 0x80000000, LENGTH = 16M
}

SECTIONS {
  . = ORIGIN(RAM);

  .text : {
    *(.text .text.*)
  } > RAM

  .rodata : {
    *(.rodata .rodata.*)
  } > RAM

  .data : {
    *(.data .data.*)
  } > RAM

  .bss : {
    *(.bss .bss.*)
    *(COMMON)
  } > RAM
}

Build:

1
2
3
4
5
6
7
riscv64-unknown-elf-gcc -O0 -g -ffreestanding -nostdlib \
  -march=rv32im -mabi=ilp32 \
  -T src/ld_demo.ld \
  -Wl,-Map=build/ld_demo.map \
  -o build/ld_demo.elf src/ld_demo.c

qemu-system-riscv32 -M virt -nographic -bios none -kernel build/ld_demo.elf

5. Read the map file like a detective

Open the map:

1
less build/ld_demo.map

Things to find:

the address range assigned to .text
where .data ended up
where .bss starts
symbol addresses for _start, g_counter, g_init

A map file is an answer key to “why is this at this address?”.

Tip

When a firmware image behaves strangely, check the map file first. Many “bugs” are actually placement mistakes.

6. Verify section addresses with readelf

1
2
readelf -S build/ld_demo.elf
readelf -s build/ld_demo.elf | grep -E '_start$|g_counter$|g_init$'

You should see:

_start at or near 0x80000000 (depending on alignment)
g_init in .data
g_counter in .bss

7. ELF → raw binary and the “no addresses” trap

Create a .bin:

1
riscv64-unknown-elf-objcopy -O binary build/ld_demo.elf build/ld_demo.bin

Now compare sizes:

1
ls -l build/ld_demo.elf build/ld_demo.bin

Warning

A raw .bin has no symbol table, no section headers, and no idea where it belongs in memory. You must supply the load address externally (boot ROM, bootloader, SoC docs, etc.).

8. Alignment and why it matters

Two common alignment realities:

instructions and data have natural alignments (word aligned, etc.)
linkers align sections so code and data remain efficient

If you ever see weird gaps, it’s often alignment.

You can force alignment explicitly:

.text : {
  . = ALIGN(16);
  *(.text .text.*)
} > RAM

9. A preview of startup code (what we’re skipping for now)

In real bare-metal systems, there’s usually a startup routine that:

sets up the stack pointer
copies .data from ROM/flash into RAM
zeros .bss
then calls main

We’re intentionally keeping early examples minimal so you can see placement without extra machinery.

Exercises

Change ORIGIN(RAM) from 0x80000000 to 0x80200000. Verify _start moved.
Add a new const char msg[] = "hi"; and confirm it appears in .rodata.
Generate a disassembly and confirm that loads/stores to g_counter use its absolute address (or a sequence that computes it).
Try -Wl,--gc-sections along with -ffunction-sections -fdata-sections and observe what unused code/data is removed.

How to test your answers

Use readelf -S and readelf -s to validate placement.
Use the map file as the ground truth.

Summary

You learned how linker scripts define a memory map, how sections are placed, and how to validate placement with map files and readelf.

Next: floating point, endianness, and bit packing-we’ll explain why double constants sometimes show up as two .word values and how to verify them with Python.