.. | ||
mmap | ||
fork-exec.c | ||
README.org |
Curso Básico da Linguagem C
- Aula 8: Processos e layout de memória
Aula 8: Processos e layout de memória
Filosofia UNIX
Doug McIlroy, que implementou o conceito de pipes no Unix, resumiu a filosofia UNIX em três princípios:
- Escreva programas que façam apenas uma coisa, mas que a façam bem feita.
- Escreva programas que trabalhem juntos.
- Escreva programas que manipulem fluxos de texto, pois esta é uma interface universal.
Se repararmos bem, esses princípios de caracterizam perfeitamente o desenvolvimento do sistema operacional Unix e a forma como ele foi projetado para ser operado.
Lembre-se…
Os sistemas operacionais parecidos com o Unix (Unix-like) podem ser descritos através de seus quatro conjuntos de softwares mais essenciais, o que também se aplica ao nosso GNU/Linux:
Componente | Unix/Unix-like | GNU/Linux |
---|---|---|
Kernel | Unix Kernel, BSD Kernel, etc… | Linux |
Biblioteca C padrão | libc |
glibc |
Shell | sh |
bash |
Utilitários da base do sistema | Programas como: cat , grep , sed , etc… |
GNU Coreutils |
Primeiro princípio: especialização
Escreva programas que façam apenas uma coisa, mas que a façam bem feita.
Separação de atribuições…
No escopo do sistema como um todo, nós podemos relacionar esse princípio com a separação entre o espaço do kernel e o espaço de usuário:
- Espaço do kernel: região de memória onde o kernel do sistema operacional executa e tem acesso privilegiado a todos os recursos de hardware e software.
- Espaço do usuário: região de memória onde os processos dos programas são executados com permissões restritas e têm o acesso ao hardware intermediado pelo kernel.
Criação de programas…
Para a escrita de programas, nós temos a libc
, que abstrai as chamadas às
funções internas do kernel (chamadas de sistema, ou syscalls) e centenas
de outras funcionalidades.
Interface padrão de operação…
Mesmo no espaço de usuário, o shell se diferencia dos demais programas da base do sistema porque, em princípio, é somente através dele que os outros programas são executados pelo usuário.
O shell é a interface padrão entre o sistema e o usuário que, através de linhas de comandos em texto, declara o que quer que seja executado.
Programas para diversas tarefas úteis…
Finalmente, o usuário tem acesso a dezenas de utilitários da base do sistema, cada um com a sua especialidade, para a realização de inúmeros tipos de tarefas.
Segundo princípio: modularidade
Escreva programas que trabalhem juntos.
Com a especialização, vem a necessidade de fazer com que cada componente do sistema, de acordo com suas atribuições, seja projetado para trabalhar com outros programas.
Linha de comandos…
Para operar o sistema, o usuário tem acesso a um terminal onde seus comandos poderão ser digitados e enviados para o shell:
+---------+ +----------+ +---------+ +--------+ | TECLADO | ---→ | | ---→ | SHELL | ---→ | KERNEL | +---------+ | | +---------+ +--------+ | TERMINAL | ↑ +---------+ | | +---------------+ | | MONITOR | ←--- | | ←--→ | NOVO PROCESSO | ←--+ +---------+ +----------+ +---------------+
Quando o shell recebe a linha de um comando, ele interpreta o que foi
digitado e, se for o caso, faz uma chamada de sistema fork
para que
o kernel crie uma cópia (clone) de seu processo. Em seguida, no processo
clonado, o shell faz uma chamada de sistema exec
, para que o kernel
substitua parte dos dados copiados do processo do shell pelos dados
do programa que será executado.
Tarefas complexas…
Cada utilitário da base do sistema é construído segundo o conceito de interface de linha de comando, ou CLI. Isso quer dizer que, além das suas especialidades, cada um deles é capaz de trocar dados com outros programas para que o usuário, a partir de programas simples, seja capaz de realizar tarefas complexas.
Por exemplo, digamos que você tenha um arquivo com uma lista de
pedidos e queira filtrar as compras realizadas em um dado mês. Você
poderia utilizar o programa grep
, que é especializado em localizar
e imprimir linhas de texto a partir de padrões descritos por
expressões regulares:
:~$ grep '03/2025' pedidos.data "Maria das Couves", "02/03/2025", "2564", "Porta copos" "Antônio dos Santos", "09/03/2025", "7544", "Toalha de mesa" "João da Silva", "01/03/2025", "3762", "Jogo de 12 talheres"
Se, além das linhas impressas, você precisar ordenar o resultado
pelos nomes dos clientes, o grep
será insuficiente sozinho, mas
você pode recorrer ao utilitário sort
para processar a saída
produzida pelo grep
escrevendo apenas um comando:
:~$ grep '03/2025' pedidos.data | sort "Antônio dos Santos", "09/03/2025", "7544", "Toalha de mesa" "João da Silva", "01/03/2025", "3762", "Jogo de 12 talheres" "Maria das Couves", "02/03/2025", "2564", "Porta copos"
Terceiro princípio: fluxos de texto
Escreva programas que manipulem fluxos de texto, pois esta é uma interface universal.
Como vimos, até aqui…
- 0 terminal recebe um fluxo de caracteres digitado em um teclado e envia para o shell;
- O shell interpreta o texto recebido e monta textos correspondendo aos argumentos que serão passados para as chamadas de sistema;
- O kernel executa a chamada de sistema e cria um novo processo para executar o programa que foi invocado… Mas não é só isso!
Além dos dados do programa (basicamente, o conteúdo de seu binário), o novo processo incluirá outros dados que já estavam registrados no processo do shell:
- A quantidade de palavras utilizadas para invocar o programa;
- A lista das palavras utilizadas para invocar o programa;
- Uma lista das variáveis que serão herdadas pelo novo processo;
- Uma lista de arquivos padrão que poderão ser utilizados para enviar e receber fluxos de texto.
Sendo assim…
- As palavras utilizadas para invocar o programa são chamadas de argumentos de linha de comando.
- A lista de variáveis herdadas pelo programa irão compor um ambiente de dados que poderão ser utilizados pelo programa.
- A lista de arquivos padrão para receber e enviar fluxos de caracteres para
o terminal são os descritores de arquivos padrão:
stdin
(entrada padrão),stdout
(saída padrão) estderr
(saída padrão de erros).
Mas existem mecanismos no kernel que possibilitam o desvio dos fluxos de
dados padrão para outros arquivos. Assim, se eu quiser enviar a saída do
meu programa para um arquivo, em vez de para o terminal, eu posso redirecionar
a saída padrão (stdout
, descritor de arquivos 1
) para esse arquivo:
ls -l > arquivos.txt
Do mesmo modo, eu poderia desviar a saída padrão de um programa para a entrada padrão de outro programa. Para isso, o kernel precisaria criar um outro tipo de arquivo, chamado de pipe, para canalizar o fluxo de texto entre os dois programas. Na linha de comandos…
:~$ grep '03/2025' pedidos.data | sort
Nesse caso, os dois programas são executados ao mesmo tempo e, enquanto o primeiro envia dados para um pipe, o segundo lê este mesmo arquivo:
+-----------------------------+ +------+ +------+ | grep '03/2025' pedidos.data | ---> | PIPE | ---> | sort | +-----------------------------+ +------+ +------+
Assim que o grep
terminar o envio de linhas de texto, o sort
será terminado.
A interface de linha de comando (CLI)
A filosofia Unix nos ajuda a compreender, de um modo mais amplo, como os sistemas Unix-like foram pensados para lidar com o hardware, possibilitarem a criação e execução de programas e serem operados. Especialmente quanto à operação do sistema pela linha de comandos, são as convenções da interface de linha de comandos (CLI), implementada no shell, que determinam como os programas e o sistema deverão lidar com os nossos comandos.
Um comando simples, seque este esquema geral:
[EXPORTAÇÕES] [INVOCAÇÃO] [ARGS...] [REDIRECIONAMENTO ARQUIVO]
- Exportações: uma ou mais variáveis que serão exportadas para o ambiente do processo do programa executado.
- Invocação: o caminho e o nome do programa que será executado.
- Argumentos: lista de palavras que serão passadas para o processo do programa como opções ou informações adicionais.
- Redirecionamento: através de operadores do shell, a saída do programa pode ser desviada para um arquivo ou um arquivo poderá ser informado para ser lido e processado pelo programa.
A invocação (o caminho e o nome do programa) sempre será o primeiro argumento da lista de argumentos.
Operadores de controle do shell
Quando a linha de um comando contém a invocação de mais de um programa, é necessário estabelecer como essas invocações se relacionam, o que é feito com os operadores de controle do shell:
- Encadeamento incondicional (
;
ou\n
): O comando seguinte será executado após o término do anterior. - Encadeamento assíncrono (
&
): O comando seguinte será executado em paralelo com o anterior e em segundo plano. - Encadeamento condicional "se sucesso" (
&&
): O comando seguinte só será executado se, e quando, o último comando executado terminar com sucesso. - Encadeamento condicional "se erro" (
||
): O comando seguinte só será executado se, e quando, o último comando executado terminar com erro. - Encadeamento por pipe (
|
): Os comandos serão executados em paralelo e a saída do primeiro será canalizada para a entrada do segundo.
O que são processos
Um processo é um conjunto de estruturas de dados que o kernel utiliza para gerenciar a execução de programas. No centro dessas estruturas de dados está uma faixa virtual contínua de endereços de memória que o kernel designará para cada programa em execução. Essa faixa virtual de endereços de memória, também chamada de memória virtual ou espaço de endereços, representa toda a memória disponível a que o processo do programa terá acesso.
Além disso, o kernel disponibiliza todas as informações sobre todos os processos
em execução na forma de um sistema de arquivos virtual (procfs) montado no
diretório /proc
. Nele, cada processo terá um subdiretório nomeado segundo seu
número de identificação (PID).
Como programas são executados
Para o sistema operacional, executar um programa significa criar um novo processo
e designar um espaço de memória para ele. Para chegar a este ponto, o programa terá
que ser invocado por outro programa já em execução (processo pai, geralmente o shell)
que, através de duas chamadas de sistema responsáveis por (chamada fork
) criar uma
duplicata do processo pai (um clone) como um novo processo e depois substituir parte
dos dados no espaço de memória dessa duplicata pelos dados encontrados no binário
do programa que será executado.
Aqui está um exemplo em C que mostra. simplificadamente, a execução de outro programa:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main(void) {
// Chamada fork...
pid_t pid = fork();
// Se o fork falhar...
if (pid < 0) {
perror("fork falhou");
exit(EXIT_FAILURE);
}
/*
Um segundo processo é criado e o código seguinte será executado
por ambos os processos (eles são idênticos!), mas com valores
de pid diferentes:
- Para o processo filho, pid == 0
- Para o processo pai, pid == PID do processo filho
Por isso temos essa estrutura if...
*/
if (pid == 0) {
// Processo filho...
printf("[Filho] PID: %d, iniciado.\n", getpid());
char *args[] = {"ls", "-l", NULL};
// Chamada exec (execvp)...
execvp(args[0], args);
// Se execvp falhar...
perror("execvp falhou");
exit(EXIT_FAILURE);
} else {
// Processo pai...
printf("[Pai] PID: %d, criou filho PID: %d\n", getpid(), pid);
printf("[Pai] Aguardando término do filho...\n");
int status;
waitpid(pid, &status, 0);
printf("[Pai] Processo filho %d terminou com status %d\n", pid, WEXITSTATUS(status));
printf("[Pai] Voltando ao controle.\n");
}
return 0;
}
Compilando e executando:
:~$ gcc -Wall exemplo.c :~$ ./a.out [Pai] PID: 1810185, criou filho PID: 1810186 [Pai] Aguardando término do filho... [Filho] PID: 1810186, iniciado. total 56 -rwxrwxr-x 1 blau blau 16280 mar 22 08:00 analise -rw-rw-r-- 1 blau blau 1549 mar 22 08:05 analise.c -rwxrwxr-x 1 blau blau 16304 mar 30 11:37 a.out -rw-rw-r-- 1 blau blau 594 mar 22 11:22 exemplo.c -rw-rw-r-- 1 blau blau 325 mar 22 10:45 fizzbuzz.c -rw-rw-r-- 1 blau blau 1743 mar 17 21:32 limites.c -rw-rw-r-- 1 blau blau 340 mar 20 14:33 str.c -rw-rw-r-- 1 blau blau 882 mar 30 11:37 teste.c [Pai] Processo filho 1810186 terminou com status 0 [Pai] Voltando ao controle.
No GNU/Linux, o shell chama a syscall
clone
, em vez defork
, eexecve
, em vez deexecvp
.
Layout de memória
Quando o processo é iniciado, ele recebe uma faixa contínua de endereços virtuais de memória, segundo o layout abaixo:
ENDEREÇOS MAIS ALTOS +--------------------------+ ---+ | Vetor Ambiente | | +--------------------------+ | | Vetor Argumentos | | +--------------------------+ PILHA (STACK) | Quantidade de argumentos | | +--------------------------+ | | Dados das funções | | +------------+-------------+ ---+ | ↓ | | | | ↑ | +------------+-------------+ | | <- Mapeamento de arquivos. | HEAP | <- Bibliotecas dinâmicas. | | <- Alocação dinâmica. +--------------------------+ | .bss | Dados globais e estáticos não inicializados. +--------------------------+ | .data | Dados globais e estáticos inicializados. +--------------------------+ | .rodata | Dados constantes (read only). +--------------------------+ | .text | Código do programa. +--------------------------+ ENDEREÇOS MAIS BAIXOS
Conteúdo do binário executável
As seções do binário do executável serão copiadas para os segmentos mais baixos desse espaço de endereços.
Região do HEAP
Acima dos dados do binário, uma grande região é designada para a alocação
dinâmica de espaços em memória para receber dados processados durante a execução
do programa: o heap. Nesta mesma região, também são carregados os conteúdos
binários das bibliotecas carregadas dinamicamente, como a glibc
, o ld-linux
e
a biblioteca vdso
, do kernel.
Região da pilha (stack)
Nos endereços mais altos, é configurada uma estrutura de dados chamada pilha. Como o nome sugere, é uma estrutura onde os dados são "empilhados" uns sobre os outros, como numa pilha de pratos.
Na base da pilha, nós encontramos um vetor de strings contendo as variáveis exportadas para o processo (vetor ambiente). Imediatamente acima, nós temos outro vetor de strings com as palavras utilizadas na linha do comando para invocar a execução do programa e, eventualmente, seus argumentos (vetor de argumentos ou parâmetros). Por último, no topo da pilha, nós encontraremos a quantidade de palavras no vetor de argumentos.
Ao longo da execução do programa, os dados das funções que forem chamadas serão incluídos no topo da pilha e serão removidos quando elas terminarem.