Pilha e chamadas de função

A pilha como caderno de contextos

Imagine um chef que precisa preparar um prato complexo. Ele lembra onde parou (endereço de retorno), coloca os ingredientes necessários à mão (variáveis locais) e anota o que precisa retornar para o próximo passo (valor de retorno em EAX). Quando termina a sub-tarefa, desfaz tudo e volta exatamente onde parou.

A pilha de chamadas (call stack) funciona assim: a instrução CALL empilha o endereço da próxima instrução (para onde voltar), e RET desempilha e salta para lá. No meio, cada função cria seu "frame" com variáveis locais e argumentos.

Animação da call stack

Avance passo a passo e observe os frames sendo criados e destruídos. Frames verdes estão sendo criados (CALL); frames vermelhos estão retornando (RET).

Prólogo e epílogo de função

; Prólogo e epílogo padrão de função x86-32
; (cdecl calling convention)

minha_funcao:
  ; === PRÓLOGO ===
  push ebp           ; salva o frame pointer do chamador
  mov  ebp, esp      ; EBP = topo da pilha = base do novo frame
  sub  esp, 16      ; reserva 16 bytes para variáveis locais
  ; agora: [ebp-4]  = var local 1
  ;        [ebp-8]  = var local 2
  ;        [ebp+4]  = 1º argumento (passado pelo chamador)
  ;        [ebp+8]  = 2º argumento
  ;        [ebp+0]  = EBP salvo do chamador
  ;        [ebp-4 de ebp salvo] = endereço de retorno

  ; === CORPO ===
  mov eax, [ebp+8]   ; carrega 1º argumento
  add eax, [ebp+12]  ; soma 2º argumento
  ; resultado em EAX (convenção cdecl)

  ; === EPÍLOGO ===
  mov esp, ebp       ; restaura ESP (descarta variáveis locais)
  pop ebp            ; restaura EBP do chamador
  ret               ; pop EIP → volta ao chamador

Convenções de chamada

// Convenções de chamada — onde ficam os argumentos?

// x86-32 cdecl (C padrão Linux/GCC): argumentos na pilha
// chamador faz:
push 5           // 2º argumento por último (direita → esquerda)
push 3           // 1º argumento
call add          // empilha EIP, salta
add  esp, 8      // cdecl: CHAMADOR limpa a pilha

// x86-64 System V ABI (Linux/macOS): argumentos em registradores
// 1º..6º argumento: RDI, RSI, RDX, RCX, R8, R9
// Além do 6º: pilha
// Retorno: RAX (e RDX para valores de 128 bits)
mov  edi, 3      // 1º argumento
mov  esi, 5      // 2º argumento
call add          // resultado em EAX/RAX

// Windows x64 (fastcall): RCX, RDX, R8, R9 (diferente!)
// Shadow space: chamador reserva 32 bytes na pilha antes de CALL
// mesmo que todos os args caibam em registradores

Inspecionando a pilha

Mini projeto: escreva uma função recursiva em C que imprime o endereço do seu próprio frame (printf("%p\n", &local_var)). Chame-a N vezes recursivamente. Observe como os endereços diminuem a cada nível — a pilha crescendo para baixo. Qual é o passo em bytes entre frames?

Projeto principal: implemente um "stack tracer" em C: use __builtin_return_address(0) (GCC) dentro de cada função para capturar o endereço de retorno. Resolva o símbolo com dladdr() e imprima o nome da função chamadora. Isso é o que backtrace() do glibc faz internamente.

Desafio extra: provoque um stack overflow controlado: escreva uma função recursiva sem caso base e meça quantas chamadas cabem antes do SIGSEGV. Depois compile com ulimit -s unlimited (Linux) e compare. Implemente a mesma função com TCO (retorno direto do resultado recursivo) e veja se o compilador otimiza o stack overflow.

Teste sua intuição

Onde você encontra isso