Scripts de linker, seções e mapas de memória

Author: Marcos Azevedo

Date: 2026-01-20

Last Modified: 2026-01-20

Reading Time: 5 mins

Section: Series

Categories: series

Tags: c-lang programming risc-v

TL;DR

Você vai aprender o que o linker realmente faz: coloca código/dados em endereços seguindo regras e produz um ELF onde endereços virtuais batem com o mapa de memória do alvo.
Vai aprender como .text, .rodata, .data, .bss e o código de startup se relacionam com VMA (Virtual Memory Address) e LMA (Load Memory Address).
Vai escrever um script de linker para um pequeno programa RV32 bare-metal, gerar um link map (.map) e converter o ELF em um .bin bruto.

Important

Trabalho com firmware e trabalho com linker script andam juntos. Se você não consegue raciocinar sobre seções e posicionamento, não consegue raciocinar com confiabilidade sobre “onde na memória” algo vive.

1. O trabalho do linker (definição prática)

Dado:

arquivos objeto (.o) contendo seções e relocações,
bibliotecas (opcional),
um layout de memória,

O linker produz:

um ELF executável com endereços finais,
símbolos resolvidos,
e (opcionalmente) um arquivo map explicando cada decisão de posicionamento.

2. Seções que você precisa conhecer

Seção	Significado	Bytes no arquivo?	Bytes na memória?
`.text`	código	sim	sim
`.rodata`	constantes somente leitura	sim	sim
`.data`	globais inicializadas	sim	sim
`.bss`	globais zero-inicializadas	não	sim

Note

.bss não tem bytes no arquivo porque é representada como “aloque N bytes e preencha com zeros”.

3. VMA vs LMA (por que podem existir dois endereços)

VMA (Virtual Memory Address): onde os bytes vivem quando o programa roda.
LMA (Load Memory Address): onde os bytes ficam armazenados na imagem que os carrega.

Em firmware bare-metal, um padrão comum é:

o código roda na RAM,
mas .data fica armazenado na flash e é copiado para a RAM no boot.

Isso implica:

o VMA de .data fica na RAM,
o LMA de .data fica na flash.

Vamos usar primeiro um layout simples de RAM única e depois explicar a ideia de “copy down”.

4. Na prática: um programa RV32 bare-metal com posicionamento explícito

Crie:

 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 ou .data dependendo da init
volatile u32 g_init    = 0x1234u; // .data

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

Crie um script de linker:

/* 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
}

Compile:

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. Leia o map file como um detetive

Abra o map:

1
less build/ld_demo.map

O que procurar:

a faixa de endereços atribuída a .text
onde .data foi parar
onde .bss começa
endereços dos símbolos _start, g_counter, g_init

Um map file é a chave para “por que isso está neste endereço?”.

Tip

Quando um firmware se comporta de forma estranha, confira o map file primeiro. Muitos “bugs” são na verdade erros de posicionamento.

6. Verifique endereços de seções com readelf

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

Você deve ver:

_start em ou perto de 0x80000000 (dependendo do alinhamento)
g_init em .data
g_counter em .bss

7. ELF -> binário bruto e a armadilha de “sem endereços”

Crie um .bin:

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

Agora compare tamanhos:

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

Warning

Um .bin bruto não tem tabela de símbolos, nem headers de seção, nem ideia de onde pertence na memória. Você precisa fornecer o endereço de carga externamente (boot ROM, bootloader, docs do SoC etc.).

8. Alinhamento e por que importa

Duas realidades comuns de alinhamento:

instruções e dados têm alinhamentos naturais (word aligned, etc.)
linkers alinham seções para que código e dados continuem eficientes

Se você vir gaps estranhos, geralmente é alinhamento.

Você pode forçar alinhamento explicitamente:

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

9. Um preview de startup code (o que estamos pulando por enquanto)

Em sistemas bare-metal reais, normalmente existe uma rotina de startup que:

configura o stack pointer
copia .data de ROM/flash para RAM
zera .bss
e então chama main

Estamos mantendo os exemplos iniciais mínimos de propósito, para você enxergar o posicionamento sem maquinário extra.

Exercícios

Mude ORIGIN(RAM) de 0x80000000 para 0x80200000. Verifique que _start se moveu.
Adicione um novo const char msg[] = "hi"; e confirme que aparece em .rodata.
Gere um disassembly e confirme que loads/stores para g_counter usam o endereço absoluto (ou uma sequência que o calcula).
Tente -Wl,--gc-sections junto com -ffunction-sections -fdata-sections e observe o que é removido.

Como testar suas respostas

Use readelf -S e readelf -s para validar posicionamento.
Use o map file como verdade fundamental.

Resumo

Você aprendeu como scripts de linker definem um mapa de memória, como seções são posicionadas e como validar isso com map files e readelf.

A seguir: ponto flutuante, endianness e bit packing, vamos explicar por que constantes double às vezes aparecem como dois .word e como verificar isso com Python.