No post anterior iniciamos o tratamento de interrupções, em especial na instalação do IDT e de exceções (interrupções de software). Fiz algumas correções no código, os códigos hexadecimais no arquivo isr.asm estavam errados. Mas nada que você não consiga olhar o código e entender a mudança.

Isso posto, vamos ao que interessa: interrupções de hardware! Você vai entender o motivo de termos separado as interrupções. É necessário primeiro entender como as interrupções de hardware ocorrem.

O processador x86 possui uma linha dedicada para ser notificado das notificações de hardware. Quando o nono bit do registrador EFLAGS (começando de zero) está setado, significa que as interrupções estão ligadas. Qualquer indivíduo que envie sinais na linha de interrupção do processador fará com que o processador pare o que está fazendo para tratar o dito cujo. E quem é que está ligado nessa linha de interrupção no processador x86? Ele mesmo, o PIC (Programmable Interrupt Controller)!

O PIC é um microcontrolador da família 8259A, um hardware muito simples (quando comparamos com um processador), responsável apenas por gerenciar as interrupções de hardware. Os periféricos são ligados nas linhas de pedido de interrupção, e o hardware é tão simples que ele só tem 8 dessas linhas disponíveis. O pedido de interrupção é popularmente conhecido como IRQ (Interrupt Request).

Epa, só 8 IRQs? Meu computador tem muito mais hardware que isso!

Você é perspicaz, pequeno jovem. De fato, 8 IRQs para todos os hardwares é muito pouco. Inclusive antigamente, no tempo de guaraná de rolha, você tinha que individualmente nos hardwares indicar qual IRQ ele iria usar. Observe na imagem abaixo de uma placa ISA Soundblaster com seus jumpers de IRQ destacados.

Era muito comum inclusive dois hardwares diferentes usarem a mesma IRQ, ai você já viu onde isso vai dar. Hoje em dia é pouquíssimo comum algum tipo de configuração desse tipo, mas fica aqui o registro.

Mas voltando ao problema original, de ter a disposição apenas 8 IRQs, uma característica interessante do 8259A é que ele pode ser usado em cascata. O que isso significa? Que você usar umas das IRQs do 8259A para ligar outro 8259A! Assim, acabamos com 8 IRQs do primeiro PIC mais 8 IRQs do segundo. Menos um na verdade: umas das IRQs do primeiro é usada para ligar o segundo). Assim, temos a nossa disposição incríveis 15 IRQs para plugar todos os hardwares.

Note que nem todo hardware precisa ser ligado ao PIC, apenas os que interrompem o processador. Por exemplo, dispositivos de saída, como monitores, não necessariamente precisam usar interrupções (hoje em dia tudo é programado, mas isso é outra história).

O diagrama de ligação do processador x86 e dos PICs é apresentado a seguir.

Obs: Se seu sistema está usando APIC (Advanced Programmable Interrupt Controller) ou IOAPIC (Intel I/O Advanced Programmable Interrupt Controller), provavelmente o funcionamento é diferente. Nesse caso, sugiro que você verifique como eles funcionam AQUI e AQUI.

Continuando, então quando um hardware ligado a um dos PICs aciona um IRQ, ele identifica por qual linha de IRQ o pedido veio, e converte essa identificação em um número binário e o armazena dentro do registrador do PIC. Por exemplo, o IRQ 0 se refere ao PIT (Programmable Interval Timer), e o veremos a seguir. Por hora, ele transforma esse número zero em zero binário (duh!) e o armazena nesse registrador. O PIC então aciona a INT Line para avisar o processador, e se ele estiver de bom humor (o nono bit do registrador EFLAGS estiver setado), o processador para o que estiver fazendo para tratar essa interrupção. O processador usa o valor do registrador do PIC para acessar a entrada correspondente no IDT e encontrar a rotina de tratamento. Para ver o post anterior sobre IDT, acesse AQUI.

Como funciona para a cascata do segundo PIC? Suponha que chegou uma IRQ na quarta linha (começando do zero) do segundo PIC. Essa interrupção veio do Mouse PS/2 (sabe o que é isso jovem?). Esse PIC armazena quatro em binário no seu registrador, e ativa a sua linha de interrupção.

Essa linha de interrupção está ligada diretamente na IRQ 2 do PIC master. Quando vem interrupções dessa linha, o PIC sabe que ocorreu uma interrupção no PIC em cascata. Ele então consulta no registrador do primeiro PIC para descobri qual foi a interrupção que ocorreu. Ele então adiciona o offset de suas próprias interrupções (ele possui 8 linhas de interrupção) e armazena em seu registrador o número resultante. Portanto, no PIC master, o que está registrado é o valor 12. Esse, por sua vez, aciona a linha interrupção para indicar um evento de interrupção ao processador.

A tabela de IRQs é bem conhecida e pode ser vista abaixo.

No fim das contas, depois das correções feitas se a interrupção se originou no PIC em cascata, o número de 0 a 15 indicará qual entrada no IDT ficará responsável por tratar a respectiva interrupção de hardware. IRQ 0 é o PIT, IRQ 1 é o teclado e assim por diante.

Algo não me cheira bem…

Os atentos perceberão que a entrada 0 do IDT já está preenchida, muito bem obrigado, pela exceção de software Erro de Divisão. Inclusive, simulamos isso no post anterior. Sendo assim, como o processador sabe se o que ocorreu foi um erro de divisão ou o timer querendo atenção?

A resposta triste é que ele não sabe. Alguém na IBM não se atentou a isso, foi um erro de design (ahhhhh quem nunca, né)?

No modo real, a BIOS remapeia as interrupções 0 a 7 para 8 a 0xf no IVT, conforme tabela abaixo:

Se você notar na tabela de exceções, notará que a maioria das exceções não acontece no modo real 16 bit. Por exemplo, não faz sentido ter uma exceção Page Fault nesse modo. A BIOS é esperta e sabe posicionar tanto as exceções de software quanto as interrupções de hardware fazendo o offset acima no IVT.

Já no modo protegido 32 bit… Ai a gente tomou na rabiola. Agora nós temos 32 exceções, que conflitam com as IRQs.

Nossa sorte é que, assim como a BIOS, nós também conseguimos reprogramar os chips para que eles respondam com offsets diferentes e assim usarem outras entradas no IDT.

Vamos programar esses dito cujos então!

O que mais se encontra na internet são códigos para reprogramar os PICs, se você quer ir direto ao ponto, acesse esses códigos (ou o meu no github) e use-o à vontade. Mas eu gosto de saber o que estou fazendo, da razão das coisas, do motivo que alguns valores são usados e detesto mais ainda Magic Numbers, pelo menos até o limite do meu conhecimento. Isso porque há ocasiões onde eles são inevitáveis, programar microcontroladores em geral tem mais relação com Engenharia Elétrica do que com Ciência da Computação. Mas faremos o possível para esclarecer o que der.

Começamos definindo as funções outb e inb (arquivo common.h).

...
static inline void outb(uint16_t port, uint8_t value) {
  asm volatile("outb %0, %1" : : "a"(value), "Nd"(port));
}

static inline uint8_t inb(uint16_t port) {
  uint8_t value;
  asm volatile("inb %1, %0" : "=a"(value) : "Nd"(port));
  return value;
}
...

São instruções para enviar ou receber dados (nesse caso, um byte) na/da porta de hardware definida como argumento. Os hardwares ficam atentos aos valores que passam nesse barramento, se algum dele casa com o endereço de hardware correspondente, o hardware reagirá de acordo.

Definimos ainda no mesmo arquivo a função io_wait, que usa a função outb definida anteriormente para enviar um valor qualquer em uma porta não usada por hardware nenhum. Isso garante que o comando emitido anteriormente tenha sido recebido e processado pelo hardware. Encare isso como uma instrução nop em um pipeline. A porta que estamos usando aqui, no caso é a 0x80 (#define UNUSED_PORT 0x80).

...
static inline void io_wait() { outb(UNUSED_PORT, 0); }
...

E por onde começamos a programar os PICs? Você começar pelo datasheet do 8259A, uma leitura (nada) agradável. Se você não é engenheiro eletricista, prevejo problemas, você encontrará coisas como os diagramas abaixo.

Lá tem como você deve encontrar o passo-a-passo de como programar o bixo, em uma língua que lembra vagamente inglês.

Eu também tenho dificuldades em ler esse tipo de documento, e perdi algum tempo relacionando o código de programação do PIC disponível (por exemplo, no Skelix e no OSDev) com o que tem no datasheet. O resumo da ópera é que o 8259A é um chip de interrupções de propósito geral, ele tem vários modos de operação, com várias combinações de opções possíveis. Mas existe um subconjunto dessas opções que se adequa à arquitetura x86 e em como os PICs estão organizados em cascata nessa arquitetura. A sequência de comandos que devemos enviar aos PICs é a seguinte:

1. Começamos enviando à porta de dados dos PICs (0x20 no master, 0xA0 no slave) o byte relativo à inicialização do PIC. Dependendo dos bits enviados, os PICs esperarão outros bytes na porta de dados deles (0x21 no master e 0xA1 no slave). Esses bytes são identificados pela sigla ICW (Initialization Command Words). Esse próprio byte que estão enviado é o primeiro deles: ICW1. Essa primeiro byte diz que estamos enviando um comando de inicialização (ICW1_INIT), que enviaremos posteriormente um byte ICW4 (obviamente depois dos bytes ICW2 e ICW3, se for o caso) (ICW1_WITH_ICW4), estamos trabalhando com PICs em cascata (ICW1_CASCADE_MODE), estamos trabalhando no modo de endereçamento das IRQ default (ICW1_INTERVAL_8), e em modo level default (ICW1_LEVEL_MODE). Esse último tem relação com a sensibilidade do onda quadrada que dispara a interrupção, e se você quer mais detalhes, veja o quadro abaixo ou vá direto no datasheet.

   

   void install_pic(int new_offset_pic_master, int new_offset_pic_slave) {
     // ICW1 (Initialization Command Words number one - Init command)
     outb(PIC_MASTER_IO_COMMAND_PORT, ICW1_INIT | ICW1_WITH_ICW4 |
                                          ICW1_CASCADE_MODE | ICW1_INTERVAL_8 |
                                          ICW1_LEVEL_MODE);
     outb(PIC_SLAVE_IO_COMMAND_PORT, ICW1_INIT | ICW1_WITH_ICW4 |
                                         ICW1_CASCADE_MODE | ICW1_INTERVAL_8 |
                                         ICW1_LEVEL_MODE);
     io_wait();

2. Com isso, os PICs sabem que estão em modo de inicialização, e esperarão pelos próximos bytes ICW. O segundo deles (ICW2) indica qual é o novo offset que os PICs devem responder. Como queremos índices depois das 32 exceções de software (ou 0x1f), queremos que o primeiro PIC responda no intervalo de 0x20 a 0x27, enquanto o segundo responda do 0x28 a 0x2f).

     // ICW2 (Offset definition)
     outb(PIC_MASTER_IO_DATA_PORT, new_offset_pic_master);
     outb(PIC_SLAVE_IO_DATA_PORT, new_offset_pic_slave);
     io_wait();

3. Como estamos trabalhando em modo cascata, os PICs esperarão o byte ICW3 para indicar como eles estão arranjados. Lembre-se, os chips 8259A são chips de propósito geral e podem ter várias formas de arranjo. Nada impediria de você cascatear mais alguns PICs no master, ou mesmo pendurar mais algum PIC no slave. Nossa missão é portanto indicar ao master em qual IRQs há PICs slaves, e indicar aos slaves a identificação deles perante o master. No nosso caso, por exemplo, temos que indicar que o slave está na IRQ 2 (0001b = IRQ 0, 0010b = IRQ 1, 0100b = IRQ 2, 1000b = IRQ 3 etc), e que o identificador do slave é 2. Se houvesse PICs nas IRQs 5 e 7, por exemplo, indicaríamos ao master o valor 10100000b, ou 0xa0. E para os respectivos PICs, indicaríamos os valores 5 e 7. A figura abaixo ajuda a entender esse processo de identificação das IRQs e do PIC.

   

     // ICW3 (Cascade mode)
     outb(PIC_MASTER_IO_DATA_PORT, ICW3_MASTER_IRQ2);
     outb(PIC_SLAVE_IO_DATA_PORT, ICW3_SLAVE_IRQ2_BINARY);
     io_wait();

4. Por fim, como indicamos inicialmente que usaríamos o ICW4, melhor apresentar o diagrama abaixo. No fim das contas, todos os bits estão zerados/default com exceção do bit zero, onde indicamos que usaremos o modo 8086/8088.

   

     // ICW4 (Operation Model)
     outb(PIC_MASTER_IO_DATA_PORT, ICW4_8086 | ICW4_NORMAL_EOI |
                                       ICW4_NON_BUFFERED |
                                       ICW4_NOT_FULLY_NESTED_MODE);
     outb(PIC_SLAVE_IO_DATA_PORT, ICW4_8086 | ICW4_NORMAL_EOI | ICW4_NON_BUFFERED |
                                      ICW4_NOT_FULLY_NESTED_MODE);
     io_wait();

5. Os procedimentos acima terminam a programação dos PICs e eles já estão operacionais e podem receber OCWs (Operation Control Words). Por fim, mascaramos todas as interrupções. Isso significa que os PICs sabe que as interrupções estão ocorrendo, eles só avisam ao processador. Fazemos isso a medida que vamos tratando as interrupções individualmente: vamos cuidar do PIT, então desmascaramos a IRQ 0. Depois, o teclado, e desmascaramos a IRQ 1 e assim por diante. Resumindo, bit 0 na IRQ, interrupção inibida. Caso contrário, a IRQ pode notificar sobre interrupções. Isso do lado dos PICs. Do lado do processador, precisamos avisar que as interrupções estão ativas, setando o nono bit (começando do zero) do registrador EFLAGS. Isso é feito com a instrução sti.

   

     outb(PIC_MASTER_IO_DATA_PORT, DISABLE_ALL_INTERRUPTS_MASK);
     outb(PIC_SLAVE_IO_DATA_PORT, DISABLE_ALL_INTERRUPTS_MASK);
   
     sti();
   }

   Pergunta de prova: há alguma outra forma de setar o bit de interrupções do processador sem usar a instrução sti? Claro que sim, só que além das instruções cli e sti, as únicas instruções que manipulam diretamente o registrador EFLAGS são as instruções pushf/popf. Você poderia fazer assim então:

  pushf
  or dword [esp], 0x200
  popf

Ou seja, manda pra pilha, faz um or bitwise com o valor 0x200 (nono bit, começando por zero) e pega o valor de volta. Mas divago, isso é só uma curiosidade.

Já podemos aproveitar e definir a operação EOI (End Of Interruption). Após “servir” uma interrupção ao processador, o processador deve enviar um comando de acknowledge, informando ao PIC que ele já tá sabendo da treta e que vai tomar as providências necessárias. Se isso não for feito, o PIC parará de enviar notificações ao processador, até que ele envie o comando EOI. O único problema é que os PICs não se conversam, eles são brigados, esses putos. Então, se IRQ originou no segundo PIC (por exemplo, a IRQ 12 do mouse PS/2), devemos enviar o comando EOI aos dois. É bem fácil de fazer isso: basta checar o número da interrupção, e se ela estiver na faixa do segundo PIC, enviamos o comando para ele também.

Para enviar o EOI ao PIC, basta enviar o valor 0x20 para as portas de comando dos PICs (0x20 para o master e 0xA0 para o slave).

void pic_send_eoi(int isr_nr) {
  if (isr_nr >= PIC_SLAVE_OFFSET) {
    outb(PIC_SLAVE_IO_COMMAND_PORT, PIC_EOI);
  }

  outb(PIC_MASTER_IO_COMMAND_PORT, PIC_EOI);
}

Moleza, hein. Vamos agora cuidar da IRQ 0.

PIT - Programmable Interval Timer

Assim como o 8259A, o PIT é um microcontrolador da família 8254, e serve para como um gerador de interrupções a uma frequência pré-determinada. O 8254 também é um microcontrolador de propósito geral, e portanto, novamente há várias opções, modos e frequências que podem ser usadas. O datasheet desse demônio pode ser encontrado AQUI.

O 8254 recebe comandos na porta 0x43, e possui três canais que respondem nas portas 0x40, 0x41 e 0x42, respectivamente. Isso serve para compor várias frequências possíveis. No nosso caso, quero gerar 1000 interrupções por segundo (1000Hz), apenas o canal 0 (porta 0x40) é suficiente. O PIT opera em aproximadamente 1.193182 MHz, então iremos programar o PIT para executar a esse valor ai dividido pela frequência desejada (vai ser 1000):

void install_pit(int desired_hz) {
  unsigned int divisor = FREQUENCY_DIVISOR / desired_hz;

Só calculamos o divisor da frequência, mas ainda não o informamos ao PIT. Primeiro vamos programar o modo de operação, que é enviar o modo para a porta 0x43. Os modos possíveis são:

Queremos então o modo binário (bit 0=0b), no modo de operação de geração de taxa (bits 1 a 3=110b), modo de acesso low byte/high byte (bits 4 e 5=11b) no canal 0 (bits 6 e 7=00b). Vou tentar explicar o que sei desses valores.

O modo BCD de 4 dígitos (Binary-Coded Decimal) possui variações, mas o mais tradicional a gente já conhece: é a representação binária de um número decimal, e para isso precisamos de 4 bits. O ponto é que não leremos informação nenhuma do PIT, queremos que ele apenas gere as interrupções, o valor interno não nos importa. Por isso o modo binário.

Quanto ao modo de operação, o Skelix usa o modo de gerador de onda quadrada, enquanto o OSDev usa Geração de Taxa. No datasheet, temos o seguinte:

Como queremos usar interrupções em tempo real, e não parece ter taaaaanta diferença assim em relação ao que o Skelix usa, ficaremos com o modo 2 mesmo, rate generator. Na página do OSDev tem uma explicação legal para quem quiser se aprofundar.

Esse trecho do código fica então assim:

  outb(MODE_COMMAND_PORT,
       BINARY_MODE | RATE_GENERATOR | LOW_BYTE_HIGH_BYTE | COUNTER_0);

Hora de enviar o divisor ao canal do PIT. Como o modo de acesso foi definido para low byte/high byte, primeiro então enviamos os o bits menos significativos do divisor ao canal zero, seguido dois 8 bits mais significativos.

  outb(CHANNEL_0_DATA_PORT, divisor & 0xff);

  outb(CHANNEL_0_DATA_PORT, divisor >> 8);

É isso. Basta agora desmascarar a IRQ 0 para que o processador seja avisado das novas interrupções do timer. A gente preserva o valor anterior alterando só o bit da IRQ 0, então basta fazer um and bitwise com o valor 0xfe (todos os bits setados, com exceção do último. Isso vai preservar o valor original de todos os bits e zerar o último bit, que é o bit relacionado à IRQ 0).

  outb(PIC_MASTER_IO_DATA_PORT, inb(PIC_MASTER_IO_DATA_PORT) & UNMASK_IRQ_0);

Isso é (quase) suficiente para terminar o PIC e PIT. Só que apesar de termos apresentado a função pic_send_eoi, a gente ainda não a usou. No primeiro tick do relógio, se não chamarmos essa função, o PIT parará de funcionar. Então, vamos tratar a IRQ 0 (arquivo interrupt.cpp):

void irq0_system_timer(int isr_nr, __attribute__((unused)) int err_code) {
  pic_send_eoi(isr_nr);
  ...
};

Os três pontinhos representam o trabalho atual do tratador da IRQ 0, que não será feito agora. Basicamente, aqui é que chamaremos o escalonador para trocar as tarefas e de fato tornar este um kernel preemptivo. Mas isso não será feito agora.

Definida o handler irq0_system_timer, precisamos instalá-lo no arquivo isr_handlers.cpp.

void (*isr_handlers[])(int, int) = {
    // exceptions
    &division_error, &default_isr_handler, &default_isr_handler,
    &default_isr_handler, &default_isr_handler, &default_isr_handler,
    &invalid_opcode, &default_isr_handler, &default_isr_handler,
    &default_isr_handler, &default_isr_handler, &default_isr_handler,
    &default_isr_handler, &general_protection_fault, &default_isr_handler,
    &default_isr_handler, &default_isr_handler, &default_isr_handler,
    &default_isr_handler, &default_isr_handler, &default_isr_handler,
    &default_isr_handler, &default_isr_handler, &default_isr_handler,
    &default_isr_handler, &default_isr_handler, &default_isr_handler,
    &default_isr_handler, &default_isr_handler, &default_isr_handler,
    &default_isr_handler, &default_isr_handler,
    // IRQS
    &irq0_system_timer, &default_irq_handler, &default_irq_handler,
    &default_irq_handler, &default_irq_handler, &default_irq_handler,
    &default_irq_handler, &default_irq_handler, &default_irq_handler,
    &default_irq_handler, &default_irq_handler, &default_irq_handler,
    &default_irq_handler, &default_irq_handler, &default_irq_handler,
    &default_irq_handler};

Se você notar direitinho, apareceu um handler general_protection_fault. Já já vai ficar claro o motivo disso…

Enfim, para fazer esse paranauê todo funcionar, basta instalarmos o PIC e o PIT no arquivo kernel.cpp. A função completa _start por enquanto está assim:

...

#define DESIRED_TIMER_HZ 1000

...

extern "C" void _start() {
  _init();
  clear_screen();

  install_gdt();
  install_idt();

  install_pic(PIC_MASTER_OFFSET, PIC_SLAVE_OFFSET);
  install_pit(DESIRED_TIMER_HZ);
  *user_entry_point = &kernel_entry;

  sched->add_task(&thread1, true);
  sched->add_task(&thread2, true);
  sched->add_task(&thread3, true);
  sched->add_task(&thread4, true);
  sched->add_task(&thread5, true);
  sched->add_task((void (*)())PROCESS1, false);
  sched->add_task((void (*)())PROCESS2, false);

  do_exit();

  while (true) {
    /* BUSY LOOP*/
  }

  /*If code has landed here, something very wrong happened...*/
  _fini();
}

E para testar se a IRQ 0 está realmente funcionando, alterei a função irq0_system_timer para imprimir um contador na tela. Ela ficou assim:

static int teste = 0;

void default_irq_handler(int isr_nr, __attribute__((unused)) int err_code) {
  pic_send_eoi(isr_nr);
  printk("IRQ ISR %x\n", isr_nr);
};

void irq0_system_timer(int isr_nr, __attribute__((unused)) int err_code) {
  pic_send_eoi(isr_nr);
  printk("IRQ0 %d\n", teste++);
  ...
};

Ao compilar e executar, você perceberá que em algum momento o PIT parará de responder.

Concurrency Hell

É agora que a mãe chora e o bebê não vê, meu amigo.

Você está todo feliz ai, tratando de problema de concorrência em modo usuário no Linux? Usando pthreads, protegendo regiões críticas, programando em CUDA, mexendo com Streams paralelas em Java… Está desesperado? Pfff meu amigo, me acompanha que agora fica tenso.

Meus skills de debugging melhoraram 1000% depois que eu consegui resolver esses problemas. Aqui, o gdb é seu amigo, mas ele é um amigo que não conversa muito, sabe? Só te responde o que você pergunta… Difícil lidar com esse cara.

Voltando ao problema, notei que em algum momento a IRQ 0 parava de responder. Obviamente que, se isso não acontecia antes, deve ser algo que introduzimos agora no código, certo?

Comecei comentando todo o trecho do meu escalonador. No fim das contas, depois da função install_pit, só tinha o busy loop no fim da função _start. E quando eu deixava assim, o PIT voltava a funcionar. 1000 vezes por segundo.

O PIC e PIT estão então, de fato funcionando. O que estava havendo afinal?

Depois de muito executar, trocar as tarefas executadas, colocar threads de kernel, processos, etc, em algum momento eu dei a sorte de interromper a execução e verificar o conteúdo dos registradores. Veja se você também nota algo esquisito:

Olhe ali logo acima do registrador EIP. Aquilo é o conteúdo do registrador EFLAGS: overflow, direct, interrupt, trap, sign, zero, auxiliary carry, parity e carry flags, nessa ordem, da esquerda para a direita. Letra minúscula, flag = 0, letra maiúscula, flag = 1. Nesse exemplo da foto, as flags que estão ativas são a Zero flag e Parity flag. Mas notou que a flag de interrupções está desabilitada? Em que momento desabilitamos as interrupções?

O problema todo, jovem, é que o diabo mora nos detalhes. De fato, não há nenhum momento que EXPLICITAMENTE desabilitamos as interrupções, não intencionalmente.

Lembra das maneiras de se alterar o EFLAGS? cli/sti e pushf/popf… Isso é feito assim que as tarefas são colocadas para executar, na função scheduler_entry:

scheduler_entry:
    push ebp
    mov ebp, esp
    call stop_kernel_timer

    mov esp, [current_task]
    lea esp, [esp + K_REGS_LIMIT]
    pushfd
    pushad
    mov [esp + ESP_OFFSET], ebp
    mov esp, ebp
    call scheduler
    mov esp, [current_task]
    popad
    popfd
    mov esp, [esp - ESP_OFFSET_FROM_LIMIT]

    call start_timer
    pop ebp
    ret

Logo após call scheduler vamos no PCB recuperar os registradores da tarefa, e os recuperamos com popad e popfd. Mas para uma tarefa recém-criada, quais são esses valores? Pois é, não definimos. E o compilador tratou de zerar os valores no construtor da classe PCB.

Assim, ao fazer o popf, o registrador EFLAGS estará todo zerado. Para a tarefa em si, isso não tinha problema nenhum, mas para o sistema, zero significa interrupções desligadas.

Então, a primeira tentativa de corrigir isso foi definindo o registrador EFLAGS como 0x202 (o primeiro bit, começando em zero, fica sempre ligado, conforme essa página dita).

Bom, tá fácil de resolver isso né? Basta ir no método PCB::config e setar esses registradores:

  // set eflags to current value (to allow interrupts, if set)
  this->kregs[8] = EFLAGS_RESERVED | EFLAGS_INTERRUPT_ENABLED;
  this->uregs[8] = EFLAGS_RESERVED | EFLAGS_INTERRUPT_ENABLED;

Piece of cake! E agora ao executar…

Agora o problema foi mais sério, não foi meu kernel que capotou (ele também) mas o QEMU. Rapaz, para derrubar o emulador é sinal que seu código está MUITO errado.

E nisso vai mais duas semanas debugando…

A volta da região crítica

Depois de muito tempo perdido (ou aprendizado, se você quiser ver o copo meio cheio), notei que em algum momento a retornar da interrupção (instrução iret) ele retornava para endereços de memória inválidos.

Na realidade, o tratador dessa interrupção estava com o registrador esp apontando para endereços fora da faixa definida para isso 0x40000 - 0x52000. O esp estava na verdade apontando para o PCB da tarefa atual. E foi ai que caiu a ficha.

Lembra da função scheduler_entry? Vamos analisá-la novamente.

scheduler_entry:
    push ebp
    mov ebp, esp
    call stop_kernel_timer

    mov esp, [current_task]
    lea esp, [esp + K_REGS_LIMIT]
    pushfd
    pushad
    mov [esp + ESP_OFFSET], ebp
    mov esp, ebp
    call scheduler
    mov esp, [current_task]
    popad
    popfd
    mov esp, [esp - ESP_OFFSET_FROM_LIMIT]

    call start_timer
    pop ebp
    ret

Lembre-se que as interrupções são implacáveis, elas podem acontecer a qualquer momento. O que acontece quando uma interrupção ocorre entre as opções mov esp, [current_task] e lea esp, [esp + K_REGS_LIMIT]? Nesse momento, estamos preparando para salvar os registradores no PCB, e o registrador esp NÃO aponta para uma pilha válida, ele está apontando para um PCB. Se uma interrupção acontecer dai até o restauro da pilha na instrução mov esp, [esp - ESP_OFFSET_FROM_LIMIT] (e isso vai acontecer, acredite em mim!), seu sistema vai para a casa do chapéu.

Isso é uma região crítica. Precisamos proteger o recurso (nesse caso, o registrador esp) para que outro concorrente não possa bagunçá-lo. Nesse caso, não tem jeito: em todo trecho que há alteração do esp para apontar para o PCB, precisamos desabilitar as interrupções:

scheduler_entry:
    push ebp
    mov ebp, esp
    call stop_kernel_timer

    cli
    mov esp, [current_task]
    lea esp, [esp + K_REGS_LIMIT]
    pushfd
    pushad
    mov [esp + ESP_OFFSET], ebp
    mov esp, ebp
    sti

    call scheduler

    cli
    mov esp, [current_task]
    popad
    popfd
    mov esp, [esp - ESP_OFFSET_FROM_LIMIT]
    sti

    call start_timer
    pop ebp
    ret

O princípio é o mesmo para a troca de contextos de processo para kernel, na função kernel_entry, mas para evitar repetições, vou omitir aqui. Consulte meu github para verificar os detalhes sórdidos.

Agora não precisamos mais definir o EFLAGS no PCB. Ao sair das funções kernel_entry e scheduler_entry o código se encarregará de ligar as interrupções com a instrução sti.

Agora vai?

Bonus Round

No fim das contas, eu ainda estava com problemas. De vez em quando ele gerava um General Protection Fault (o motivo de eu ter instalado um handler para ver o que estava acontecendo), às vezes disparava um Invalid Opcode e os handlers default sem eu ter solicitado… algo definitivamente ainda estava errado. Ele com certeza estava executando códigos que não foi eu quem escrevi.

Como não acreditamos em Poltergeist na computação, em algum momento percebi que ele estava acessando a Vtable da classe Scheduler. Oxi, mas eu não estava mais usando a classe derivada FairScheduler, por qual motivo o método virtual sched estava sendo invocado se meu objeto não era do tipo FairScheduler? Vamos relembrar como essa classe está:

class Scheduler {
...

public:
  ...
  virtual ~Scheduler() = default;
  void operator delete(void *, unsigned int) {};
  virtual void sched(QueueNode<PCB> *);
};

class FairScheduler : public Scheduler {
public:
  void sched(QueueNode<PCB> *);
};

Não fazia sentido. Notei também que isso acontecia quando eu tentava fazer um unblock no lock…

extern Scheduler sched;

void Lock::lock_acquire() {
  if (this->mutex.exchange(true)) {
    sched.block(this);
  }
}

void Lock::lock_release() {
  if (this->blocked != nullptr) {
    sched.unblock(this);
  } else {
    // Util::printk("empty queue\n");
    this->mutex.store(false);
  }
}

Mas calma lá! No arquivo scheduler.cpp, para usar o FairScheduler, alteramos a variável sched para usar ponteiro!

// FairScheduler fairSched;
// Scheduler *sched = &fairSched;

Scheduler roundRobinSched;
Scheduler *sched = &roundRobinSched;

Considerando que estamos falando da mesma coisa (por isso o extern no arquivo lock.cpp), no arquivo scheduler.cpp a variável sched é um ponteiro, mas no arquivo lock.cpp ele é um objeto! Bom, se for só isso, é fácil de alterar:

extern Scheduler *sched;

void Lock::lock_acquire() {
  if (this->mutex.exchange(true)) {
    sched->block(this);
  }
}

void Lock::lock_release() {
  if (this->blocked != nullptr) {
    sched->unblock(this);
  } else {
    // Util::printk("empty queue\n");
    this->mutex.store(false);
  }
}

Isso é um bug que estava dormente há muito tempo e só se manifestou agora. Magicamente, agora tudo funcionou!

O código, até o momento está no meu github.

Qual é a moral da história dessa linda fábula que acompanhamos até o momento? Não cometa erros, não programe bugs. Espero ter ajudado! :D

Anterior

No post anterior nós finalmente finalizamos o P2, e começamos agora o P3, um Kernel Preemptivo, YAY! Mas o que isso significa?

Primeiro, até o momento, as tarefas precisam explicitamente ceder a CPU para as outras. Isso era feito via função do_exit para as threads do kernel e syscall yield para os processos. Agora, haverá um mecanismo externo que pode interromper a tarefa a qualquer momento.

Que brisa é essa?

A arquitetura x86 é uma arquitetura orientada a eventos. Significa que a CPU reage a estímulos externos e responde de acordo. Mas como isso funciona e qual seria a alternativa se esse mecanismo não existisse?

Suponha que você digitou uma tecla qualquer no seu teclado. Se o evento não foi informado a CPU, ela deve periodicamente consultar o hardware do teclado para saber se alguma tecla foi pressionada, e em caso positivo, verificar o seu código. Esse mecanismo é conhecido como Polling e é bem conhecido em várias aplicações.

Perceba que já usamos esse mecanismos de uma certa forma. As instruções in e out, que usamos para habilitar o A20 Gate nesse post aqui, são usadas para fazer polling no hardware.

Para isso funcionar, a tarefa deve voluntariamente ceder a CPU para que ela vá buscar os dados no hardware. Se a tarefa não colaborar, pouco pode ser feito. Além disso, pode ser que você vá fazer o polling e o hardware não tenha nada a informar (nenhuma tecla foi pressionada por exemplo). Nesse caso, estamos desperdiçando valiosos ciclos de CPU fazendo nada. Um desperdício de recursos!

Por isso, a arquitetura x86 (e qualquer arquitetura moderna, como ARM) trabalha com o conceito de interrupções. Sempre que necessário, o hardware envia um pedido de interrupção para a CPU. Esta para o que está fazendo, atende o hardware e volta para a tarefa como se nada tivesse acontecido. Na verdade, essa é toda a magia da coisa: a tarefa não faz ideia de que foi interrompida, e para ela esse mecanismo é totalmente transparente.

Ok, e como fazemos para isso funcionar na prática? A resposta curta é que basta instalar o IDT e as funções tratadoras das interrupções. A resposta longa vem a seguir.

Interrupt Descriptor Table

Se você acompanhou a saga da instalação do GDT nesse post aqui, adianto que o IDT (Interrupt Descriptor Table) é igual, mas é diferente. Igual porque o IDT também é um registrador especial, de 48 bits, que armazena o endereço base e o tamanho da tabela, tal qual o GDT. Cada entrada na tabela do IDT também tem 8 bytes, assim como as entradas do GDT.

Mas é diferente porque cada entrada nessa tabela é equivalente ao IVT (Interrupt Vector Table) da BIOS, que, sinto lhe dizer, não existe mais.

IVT?

Para entendermos o IDT, acredito ser pedagógico se dominarmos o IVT. Quando o computador é ligado, a CPU carrega o código da ROM BIOS, que faz várias checagens e executa os códigos contidos nesse chip, notadamente o POST (Power On Self Test). Uma das coisas que a BIOS faz é instalar o IVT na posição 0x0 da memória. Lembre-se que nesse momento a CPU está operando em modo real, com segmentação, em 16 bits.

Então, cada entrada no IVT contém 4 bytes: 2 bytes para o cs e 2 bytes para o offset. cs:offset indica o endereço da função que trata as interrupções. Quando você está nesse modo então, se você pressionar uma tecla, o hardware do teclado disparará um pedido de interrupção (também chamado de IRQ - Interrupt Request). As interrupções são exclusivas de cada hardware, assim quando um pedido desse chega, a CPU sabe de qual hardware ele está vindo. O teclado, por exemplo, envia pedidos pela IRQ 1. Um mouse PS2 envia pedidos de IRQ 12. Para ver outros exemplos, veja aqui.

Pois bem, esses números são usados pela CPU como índices para acessar as entradas do IVT e buscar a função que trata essa solicitação. Assim, no caso do teclado, a CPU carregará o cs:offset da entrada 1 e fará um call/jmp para esse endereço. E o que essa função faz? Isso depende do hardware. No caso do teclado, a função usa instruções in/out para consultar os registradores do teclado e descobrir qual tecla foi pressionada.

Parece funcionar bem certo? Larga de ser burro e usa esse IVT para tratar as interrupções então, a tabela já foi construída pela BIOS, para que refazer o serviço?

Basta usar o IVT então!

Tenho péssimas notícias jovem. Uma vez que você mudou a CPU para o modo Protegido/32bits, o IVT foi perdido. Uma, porque não sabemos onde estão os endereços das funções que foram instaladas no IVT. Outra, porque aquelas funções usam manipulação de dados em modo real de 16 bits, que não equivale aos registradores de segmento usados em modo 32 bits. Enfim, não é possível.

Voltando ao IDT

Obviamente há de se haver um jeito de instalar tratadores de interrupções para o modo protegido/32bits. E há mesmo, e nesse caso, voltamos ao IDT. Nossa missão é então, em cada entrada do IDT, o tratador correto da interrupção. Vamos então ver como é uma típica entrada do IDT.

A entrada tem então 8 bytes, e é ligeiramente mais simples do que uma entrada do GDT. Os campos segment select e offset tem um significado similar ao IVT: no fim das contas é o endereço da função que vai tratar a interrupção. A diferença é que o seletor de segmento aponta para uma entrada válida para um seletor de código do GDT. Em especial, pois no futuro o código de usuário estará rodando em outro anel de proteção do kernel e por isso o registrador cs selecionará um segmento diferente do seletor de código do kernel, que executa no anel de proteção 0.

Adianto aos aflitos que ainda não vamos separar o código de usuário para o Ring 3. Isso vai acontecer apenas no P5 - memória virtual. Adianto então que as tarefas estarão rodando no mesmo seletor de segmento do kernel, Ring 0, e todos eles apontam para a mesma entrada: cs = 0x8 (para você se situar, lembre-se que os seletores de segmento de dados ds, es, fs, gs e ss possuem valor 0x10). Portanto, todas as entradas do IDT possuem esse segment selector igual a 0x8, e o offset é o endereço da função (32 bits partidos ao meio, 16 para cada). Até aqui tudo bem?

Os bits 32 a 39 são reservados. Basta informá-los como zero, assim como o bit 44.

O bit 47 é o bit Present, indica que a entrada é válida e está ativa. Basta deixar com o valor 1.

Os bits 45 e 46 representam o DPL (Descriptor Privilege Level). Com dois bits, você sabe que os valores possíveis são 0, 1, 2 e 3, e você já deve ter associado aos anéis de proteção, corretamente. Mas o que esse valor significa neste contexto aqui?

Bom, esse valor só é usado quando essa entrada do IDT está relacionado a uma interrupção de software invocada com a instrução int. Você vai querer por exemplo que sua syscall seja disponível aos usuários, portanto, no Ring 3. Do restante, deixe sempre em Ring 0. As interrupções de hardware ignoram esse valor.

Por fim, os bits 40 a 43 representam o Gate Type. Vale a pena explicar um pouco mais isso.

Gate type

Temos quatro bits para o Gate Type, mas apenas 5 valores válidos.

Task Gate

O valor 0x5 indica que essa entrada é um Task Gate, usada quando há troca de contexto via hardware, usando portanto entradas TSS no GDT. Nesse caso, o campo offset não é usado e deve estar zerado, pois não há função de tratamento da interrupção. Em vez disso, o estado do processador é salvo no TSS e o endereço da código interrompido é armazenado no campo Task Link no TSS.

Não estamos fazendo troca de contexto via hardware, então não usaremos esse valor.

Interrupt Gate

Os valores possíveis para esse tipo são 0x6 para um interrupt gate de 16 bits e 0xe para um interrupt gate de 32 bits. Obviamente o que nos interessa é o valor 0xe (1110b). Interrupções de hardware usam esse tipo de gate, bem como as instruções de software int. No caso de uma IRQ ou na instrução int, o valor “informado” é o índice para essa entrada no IDT, e o processador carrega o seletor de segmento e o offset para a função que trata essa interrupção. É o tipo mais comum de interrupção. É importante destacar que esse tipo de gate desabilita as interrupções automaticamente e as reabilita quando o tratamento é encerrado, logo após a instrução iret.

Trap Gate

Esse tipo de gate possui valores válidos de 0x7 para 16 bits e 0xf para 32 bits. Novamente, nosso valor de interesse é o de 32 bits, então 0xf. Esse tipo é pensado para ser usado no tratamento de exceções, por exemplo, uma divisão por zero.

Pois é, não sei se te ocorreu, mas há várias situações em que uma exceção pode ocorrer. Além da divisão por zero, por exemplo, há outros exemplos, como opcode inválido, ou um page fault, quando a memória virtual já está sendo usada, ou mesmo se você tentar usar as instruções in, out, lgdt no Ring 3, por exemplo.. Em qualquer desses casos, a CPU interrompe a tarefa atual e procura um tratador adequado.

Note que, do ponto de vista de procedimento, Interrupt Gate e Trap Gate são virtualmente iguais. Inclusive, na sua entrada do IDT, você pode usar Trap Gate para tratar IRQs ou Interrupt Gate para tratar exceções. A diferença ainda não foi dita: na verdade uma Trap Gate não desabilita as interrupções e as reabilita ao final, com iret.

As consequências são grandes, pense por um momento. Se você está tratando uma divisão por zero via Trap Gate, como as interrupções ainda estão habilitadas, pode chegar uma interrupção de teclado, por exemplo. Nesse caso, a função que está tratando a divisão por zero será interrompida para atender a interrupção de teclado. Se isso é desejável ou mesmo se isso pode acontecer depende de cada caso.

Você vai perceber que as primeiras 32 entradas do IDT são exceções, e por isso, são instaladas como Trap Gate. As demais serão Interrupt Gate.

Exceções

Exceções ocorrem quando o processador entra em um estado indefinido, seja por erros ou falhas, como por exemplo, a falta de página na memória. Exceções podem ou não informar um código de erro para o tratador saber o que aconteceu. As exceções podem ser divididas:

• Falhas: se tratado adequadamente, essa exceção retorna para a mesma instrução que causou a falha (uma divisão por zero, talvez?). Nesse caso, a instrução que causou o problema pode ser reexecutada se o problema for corrigido. Exemplos são: Divisão por zero, TSS inválido, Falta de página, etc.

• Traps: São causadas intencionalmente, e o retorno do tratamento dessa interrupção acontece na próxima instrução que originou o evento. Exemplos de traps são: Debug, Breakpoint e Overflow (mas um tipo bem específico que só acontece quando o Overflow Flag no registrador EFLAGS está setado, e a instrução into é executada). Obs: Não confundir o Trap Gate com uma exceção do tipo Trap. São coisas diferentes, apesar de relacionadas.

• Abortar: Esse tipo de exceção, em geral, é irrecuperável, e o processo que causou isso é morto sem grandes cerimônias. Um tipo de exceção que tem esse comportamento é a Dupla Falta. Imagine por exemplo que um determinado processo teve uma falha de página. Mas a função que trata falhas de página também não está na memória, causando uma nova falha de páginas novamente. Nesse caso, não há o que se fazer, já que nenhuma das falhas de páginas que ocorreram podem ser tratadas, e o processo é portanto encerrado.

A arquitetura x86 tem uma lista bem definida de exceções, e o número no vetor equivale a entrada no IDT conforme imagem abaixo:

Você ainda está falando de Gate Type no IDT? Show me the code!

Você é muito apressado, calma calabreso! Vamos começar definindo as definições (pleonasmo intencional).

No novo arquivo idt.h, vamos criar a classe IDT.

...  #define PRESENT_BIT (1 << 7) #define DPL_RING_0 0x0  ...  class IDT {   uint16_t offset_bytes_0_1;   uint16_t segment_selector_bytes_2_3{TYPE_CODE_SEG};   uint8_t reserved_byte_4{0};   uint8_t type_dpl_present_byte_5{PRESENT_BIT | ((DPL_RING_0 & 0x3) << 5)};   uint16_t offset_bytes_6_7; ... } __attribute__((__packed__));  ...

Essa classe representa aquela estrutura de 8 bytes já mostrada anteriormente. Perceba que já defino alguns valores de antemão: o seletor do segmento é igual a TYPE_CODE_SEG (definido com o valor 0x8 no arquivo gdt.h) e o byte de tipo de gate nós já setamos o bit Present, e também colocamos os bytes equivalentes ao Ring 0 na posição certa. O que mais falta então? O que vai mudar de entrada para entrada é o endereço da função tratadora (offset) e o tipo de gate. Isso é feito no médodo install_idt_entry da classe IDT.

...  enum GATE_TYPE {   INVALID_0,   INVALID_1,   INVALID_2,   INVALID_3,   INVALID_4,   TASK_GATE,   INT_GATE_16BIT,   TRAP_GATE_16BIT,   INVALID_8,   INVALID_9,   INVALID_A,   INVALID_B,   INVALID_C,   INVALID_D,   INT_GATE_32BIT,   TRAP_GATE_32BIT };  class IDT { ... public:   void install_idt_entry(void (*isr_entrypoint)(void), GATE_TYPE type) {     this->offset_bytes_0_1 = (uint32_t)*isr_entrypoint & 0x0000ffff;     this->offset_bytes_6_7 = (uint32_t)*isr_entrypoint >> 16;     this->type_dpl_present_byte_5 |= type;     ...   }; } __attribute__((__packed__));  ...

Basicamente, quebramos o endereço da função isr_entrypoint em duas partes, e as colocamos no lugar certo na entrada do IDT. E fazemos o mesmo para o tipo de gate. Lembra que temos 4 bits para isso, mas nem todos os valores possíveis estão disponíveis? Por isso usamos essa enum. E como o tipo de gate fica nos bits menos significativos do byte type_dpl_present_byte_5, uma operação OR bitwise é suficiente (operador |= ).

E teremos também a Classe IDTPointer, e tal qual o GDTPointer, armazena o endereço da tabela de entradas IDT e o tamanho.

...  class IDTPointer { public:   uint16_t size{0};   uint32_t entries_address{0};    IDTPointer(uint16_t size, int32_t address)       : size(size), entries_address(address) {} } __attribute__((__packed__));  ...  void install_idt();  ...

No código acima definimos ainda a função install_idt que é chamada pelo kernel para instalação das entradas, nos mesmos moldes do GDT. Vamos ver o que essa função faz, ela está no arquivo idt.cpp:

#include "include/idt.h" #include "include/exceptions.h"  static IDT entries[256]; static IDTPointer idtp((uint16_t)(sizeof(entries) - 1), (uint32_t)&entries[0]);  extern "C" void (*isr[])(void); extern "C" uint32_t isr_size; extern "C" void default_isr(void);  void install_idt() {   unsigned int i = 0;   while (i < isr_size) {     entries[i].install_idt_entry(isr[i],                                  i < 32 ? TRAP_GATE_32BIT : INT_GATE_32BIT);     i++;   }    while (i < TOTAL_ISR) {     entries[i].install_idt_entry(&default_isr, INT_GATE_32BIT);     i++;   }    asm("lidt %0" : : "m"(idtp)); }

Uma diferença notável do IDT em relação ao GDT é que a tabela do IDT tem tamanho fixo, 256 entradas. Lembre-se que o GDT tem tamanho variável a depender de quem o programa.

O que fazemos aqui é basicamente instalar as 256 entradas do IDT. Para algumas, temos tratadores definidos no vetor de ponteiros de função isr (que não está aqui e será mostrado em um momento oportuno. A variável isr_size também indica o tamanho desse vetor de ponteiros de função. Sabemos que as as primeiras entradas do IDT são exceções, conforme tabela, então, o tipo de gate é TRAP_GATE_32BIT. O restante será interrupções de hardware, portanto INT_GATE_32BIT.

Obs: A informação acima não é inteiramente verdade, há uma entrada no IDT além das listadas do tipo Trap Gate: é justamente a entrada que trata syscalls. Quando ela for instalada, fazemos os ajustes necessários.

Depois das entradas conhecidas, preenchemos o restante das entradas com tratadores de interrupção que não faz nada, no caso, a função externa default_isr.

Por fim, carregamos o registrador IDTR e instalamos o IDT usando a instrução especial, que só pode ser usada no Ring 0, lidt.

E é isso, IDT instalado. Fácil né?

Ei, espera um minuto…

Muito suspeito aquelas declarações externas ali. Por que esse código não está ai junto? Qual é a pegadinha?

Então, de fato tem uma GRANDE pegadinha. Quando uma uma interrupção acontece, há alguns passos que o processador faz antes de realmente chamar a função que trata a interrupção (lembrando que isso vale para x86 vanilla. Isso é diferente para x86_64 ou quando há mudança de anel de proteção):

1. O processador empilha o registrador eflags

2. O processador empilha o registrador cs

3. O processador empilha o registrador eip (se é a instrução atual ou a próxima, depende da interrupção/exceção)

4. Se houver um código de erro, o processador empilhará esse código.

5. O processador carrega o cs:offset da respectiva entrada no IDT e pula para esse código.

Quando tem mudança do anel de proteção (por exemplo, do Ring 3 para Ring 0), antes de empilhar o registrador eflags, o processador empilha os registradores ss e esp, nessa ordem. No nosso caso, o código está rodando no mesmo anel de proteção do kernel então os registradores ss e esp não são empilhados.

Assim que o processador começa a executar o código cs:offset, devemos preservar o estado da tarefa anterior. Diferente da troca de contexto, o registrador eflags já foi salvo, então é desnecessário usar a instrução pushf. Mas salvar o restante dos registradores ainda é importante. Portanto as instruções pusha/popa ainda serão usadas. Por fim, a função retorna com iret, e não ret, como seria um código tradicional.

Perceba que com todos esses detalhes, é difícil usar C/C++ puro pois o código tentará criar os registros de ativação, retornar com ret, etc. Até dá, mas acredite, o código assembly para tratar disso é mais legível que o código C/C++ equivalente.

Chega de conversa! Vamos então conferir o código no arquivo isr.asm, mas por partes:

global isr, isr_size, default_isr extern isr_handlers  ...  %macro isr_no_error 1 isr%1:     push 0     push %1     jmp prepare_isr %endmacro  %macro isr_error 1 isr%1:     push %1     jmp prepare_isr %endmacro  ...

Primeiro, como há interrupções que empilham código de erro e outras não, criamos macros para uniformizar isso: quando o processador não empilha um código de erro, nós empilhamos um valor arbitrário (no caso, push 0). Isso servirá para uniformizarmos o tratamento das interrupções, todas elas chegarão com a mesma estrutura de pilha ao tratador. Outra coisa que empilhamos é o número da interrupção: isso servirá para acessarmos um vetor de ponteiros de função com o tratador definitivo. Por exemplo, se a exceção for divisão por zero, ele empilhará zero. Se for Opcode Inválido, ele empilhará 6 e assim por diante. Depois disso ele pulará para o rótulo prepare_isr.

Usamos essa macro assim: pegando como exemplo a divisão por zero. Ela é identificada pelo índice 0. Então fica:

isr_no_error 0x00 ; Division Error

Do ponto-e-vírgula para frente é comentário. Então isr_no_error 0x00 é traduzido diretamente para:

isr0x00:     push 0     push 0x00     jmp prepare_isr

Sacou? A ideia é não fica repetindo código. Para definir as 32 exceções da tabela previamente apresentada, considerando se tem ou não código de erro, fica assim:

isr_no_error 0x00 ; Division Error isr_no_error 0x01 ; Debug isr_no_error 0x02 ; Non-maskable Interrupt isr_no_error 0x03 ; Breakpoint isr_no_error 0x04 ; Overflow isr_no_error 0x05 ; Bound Range Exceeded isr_no_error 0x06 ; Invalid Opcode isr_no_error 0x07 ; Device Not Available isr_error 0x08 ; Double Fault isr_no_error 0x09 ; Coprocessor Segment Overrun isr_error 0x10 ; Invalid TSS isr_error 0x11 ; Segment Not Present isr_error 0x12 ; Stack-Segment Fault isr_error 0x13 ; General Protection Fault isr_error 0x14 ; Page Fault isr_no_error 0x15 ; Reserved isr_no_error 0x16 ; x87 Floating-Point Exception isr_error 0x17 ; Alignment Check isr_no_error 0x18 ; Machine Check isr_no_error 0x19 ; SIMD Floating-Point Exception isr_no_error 0x20 ; Virtualization Exception isr_error 0x21 ; Control Protection Exception isr_no_error 0x22 ; Reserved isr_no_error 0x23 ; Reserved isr_no_error 0x24 ; Reserved isr_no_error 0x25 ; Reserved isr_no_error 0x26 ; Reserved isr_no_error 0x27 ; Reserved isr_no_error 0x28 ; Hypervisor Injection Exception isr_error 0x29 ; VMM Communication Exception isr_error 0x30 ; Security Exception isr_no_error 0x31 ; Reserved

De boa né? Entendendo a ideia da parada, fica mais fácil de entender o que está acontecendo. Agora vamos ver o rótulo prepare_isr:

prepare_isr:     pusha     mov ebp, esp      mov ebx, [ebp+32] ; isr_nr on the stack     push dword [ebp+36] ; err_code to the handler     call [isr_handlers + 4*ebx]     add esp, 4 ; remove err_code off the stack      popa     add esp, 8 ; remove error code and isr_nr from stack     iret

Começamos empilhando os registradores de propósito geral. Depois ajustamos o registrador ebp para podermos acessar os parâmetros na pilha de uma forma inteligente.

Para prosseguirmos, precisamos entender como está o layout da pilha até esse momento. A imagem abaixo mostra isso.

Então, o que estamos fazendo afinal? Colocamos em ebx o valor de isr_nr que está na pilha, ele servirá de índice para acessar o tratador da interrupção correto (na chamada call [isr_handlers + 4*ebx]). Antes, reempilhamos o valor err_code (push dword [ebp+36]) para o tratador, assim, todos os handlers podem ter a mesma assinatura: void isr_handler (int);

Você deve ter notado ainda que o isr_handlers é definido como externo no arquivo isr.asm. Eu mostro esse depois, e esse não tem segredo, você vai ver. Mas vamos continuar a função prepare_isr. Depois que a instrução call retorna, nós removemos o err_code da pilha (add esp, 4), desempilhamos todos os registradores (popa), e desempilhamos isr_nr e err_code (e o err_code é desempilhado por nós, mesmo se foi o processador quem empilhou!). A instrução iret se encarrega de desempilhar os registradores eip, cs e eflags.

Beleza, mas, se me lembro bem, o install_idt usa uma variável isr (e isr_size)… você ainda não mostrou nada relacionado a ela! Ela é usada aqui no arquivo idt.cpp nesse trecho:

    entries[i].install_idt_entry(isr[i],                                  i < 32 ? TRAP_GATE_32BIT : INT_GATE_32BIT);

Com as macros definidas, é fácil definirmos a variável isr no arquivo isr.asm:

isr: dd   isr0x00, isr0x01, isr0x02, isr0x03, isr0x04,  isr0x05, isr0x06, isr0x07, isr0x08, isr0x09,  dd   isr0x10, isr0x11, isr0x12, isr0x13, isr0x14, isr0x15, isr0x16, isr0x17, isr0x18, isr0x19,  dd   isr0x20, isr0x21, isr0x22, isr0x23, isr0x24, isr0x25, isr0x26, isr0x27, isr0x28, isr0x29,  dd   isr0x30, isr0x31 isr_end:  isr_size: dd (isr_end - isr)/DWORD_SIZE

Só isso. No fim das contas, como eu havia dito, é um vetor de ponteiros para função (ou algo similar a isso). São esses endereços que são efetivamente instalados no IDT.

Pode ter ficado confuso, é muito vai-e-volta, mas vamos exemplificar. Suponha que uma divisão por zero ocorreu. O processador vai fazer aqueles empilhamentos malucos que já explicitamos, e ele vai carregar o cs:offset do IDT. E qual é esse valor? É 0x8:isr0x00. A função empilha o err_code (zero) e isr_nr (também zero) e pula para prepare_isr. Lá, os registradores são empilhados e ele chama a função definida no vetor isr_handlers na posição zero. Depois ele faz um clean-up e segue a vida.

Vamos ver o que tem em isr_handlers então. Não poderia ser mais simples, está no arquivo isr_handlers.cpp:

#include "include/exceptions.h"  void (*isr_handlers[])(int) = {     &division_error,      &default_isr_handler, &default_isr_handler,     &default_isr_handler, &default_isr_handler, &default_isr_handler,     &invalid_opcode,      &default_isr_handler, &default_isr_handler,     &default_isr_handler, &default_isr_handler, &default_isr_handler,     &default_isr_handler, &default_isr_handler, &default_isr_handler,     &default_isr_handler, &default_isr_handler, &default_isr_handler,     &default_isr_handler, &default_isr_handler, &default_isr_handler,     &default_isr_handler, &default_isr_handler, &default_isr_handler,     &default_isr_handler, &default_isr_handler, &default_isr_handler,     &default_isr_handler, &default_isr_handler, &default_isr_handler,     &default_isr_handler, &default_isr_handler};

Como eu disse, e eu espero que você tenha acreditado em mim, é literalmente um vetor de ponteiros de função, e agora sim, os tratadores de verdade das interrupções.

Para esse post, defini apenas 2 exceções: erro de divisão e opcode inválido. O restante usa um tratador genérico. E agora podemos usar C/C++! Primeiro, o arquivo exceptions.h:

#ifndef __EXCEPTIONS_H #define __EXCEPTIONS_H  void default_isr_handler(int);  void division_error(int);  void invalid_opcode(int);  #endif

Funções com a mesma assinatura, hã? E o corpo dessas funções fica assim:

#include "include/exceptions.h" #include "include/util.h"  void default_isr_handler(int err_code) {   printk("default_isr_handler was called: err_code: %d\n", err_code); }  void division_error(__attribute__((unused)) int err_code) {   panic("Divisior error"); }  void invalid_opcode(__attribute__((unused)) int err_code) {   panic("Invalid Opcode"); }

O handler default só imprime o código de erro e retorna. As outras duas funções usam a função panic, que é um printk que entra em um loop infinito. Isso porque, você se recorda, essas exceções retornam para a mesma instrução que causou o problema, lembra? Não vou testar isso no contexto de tarefas, vou testar direto no kernel. Então, não há “processo” para derrubar. Se retornássemos como seria o fluxo normal, ele tentaria executar novamente as instruções problemáticas, e ficaria chamando para sempre os tratadores de interrupção. Não se preocupe, isso mudará depois.

Outro ponto de atenção é que para as funções division_error e invalid_opcode, não há razão para usarmos o parâmetro err_code. Por esse motivo, instruímos o compilador a não reclamar pelo fato de não o usarmos. Coisa besta, mas que deixa o código mais robusto e gera menos warnings na saída do compilador.

É isso?

Agora sim, isso é tudo. Pelo menos, da parte que queria apresentar nesse post. Você deve ter notado que não temos tratadores para as IRQ ainda. Fique calmo que logo elas vem.

Para testar isso, fiz dois testes. Logo após instalar o IDT, causei uma divisão por zero:

...  extern "C" void _start() {   _init();   clear_screen();    install_gdt();   install_idt();   *(uint32_t *)(USER_ENTRY_POINT) = (uint32_t)&kernel_entry;    volatile int a = 3;   volatile int b = 0;   printk("%d\n", a / b);

e o resultado é:

Para o opcode inválido:

...  extern "C" void _start() {   _init();   clear_screen();    install_gdt();   install_idt();   *(uint32_t *)(USER_ENTRY_POINT) = (uint32_t)&kernel_entry;    ...    asm("ud2 " : :);

o resultado é:

E é isso ai, tudo funcionando!

No próximo post pretendo tratar pelo menos da IRQ0, que trata das interrupções do timer do sistema. Essa é a principal ferramenta usada para fazer um kernel preemptivo, pois é um temporizador que de tempos em tempos interrompe o processador, e usamos isso para fazer a troca de contexto das tarefas.

Enquanto isso não ocorre, fique com o código desse post, que está disponível no meu github.

Queria agradecer às páginas OSDev e Skelix, em que baseei boa parte do conteúdo aqui apresentado. Em especial à OSDev, há muito conteúdo complementar relacionado que sugiro a leitura1 2 3 4 5 6:

Anterior

Próximo

Antes de iniciar esse post, preciso complementar uma informação que faltou no post anterior. O método de chamada de sistema daquele post se parece muito em como as funções virtuais funcionam em C++. Funções virtuais podem ser sobrecarregadas, significando que o endereço da função original na classe base é alterada pelo novo método. Como isso é resolvido dentro do compilador? Bom, todos os objetos que possuem métodos virtuais possuem uma estrutura chamada VTABLE, que contempla os ponteiros das funções virtuais.

Quando um objeto de classe derivada é construído e atribuído a uma referência da classe base, o compilador troca o endereço da método da classe base para este objeto. O código continua chamando os métodos da classe base, mas o compilador agora tem um ponteiro de ponteiro: ele sabe o endereço da VTABLE desse objeto, que contém um outro ponteiro do método sobrescrito. Por este motivo, esse método de despacho de ponteiros de ponteiro de função se parece com mecanismo usado para syscall aqui. Se você está construindo um compilador que compila códigos orientados a objeto, agora sabe como fazer sobrescrita de métodos.

Por que estou falando disso? Porque está no momento de fazer o crédito extra do P2, que pede:

Então é hora de fazer um escalonador justo, que sempre escolhe os processos que tiveram o menor tempo de CPU a cada rodada. Pra isso a gente precisa saber quanto tempo cada tarefa levou, e o lugar para armazenar essa informação, como você já deve ter deduzido, é no PCB. Tomei a liberdade de medir 4 coisas:

...
class PCB {
...
  unsigned long long kernel_cpu_time_last_sched{0};
  unsigned long long user_cpu_time_last_sched{0};
  unsigned long long total_kernel_cpu_time{0};
  unsigned long long total_user_cpu_time{0};

Isso para medir o tempo de CPU desde o último escalonamento da tarefa, tanto do kernel no contexto do processo ou para as threads de kernel, quanto o tempo de cpu de usuário, válido apenas para tarefas de usuário (processos).

Fiz assim para evitar que tarefas que estejam executando a muuuuuito tempo, quando outra nova tarefa seja adicionada, esta não fique rodando sozinha até que ela iguale o tempo da tarefa antiga.

Com isso, nosso PCB ganha novos métodos:

  void set_kernel_cpu_time(unsigned long long time) {
    this->kernel_cpu_time_last_sched += time;
    this->total_kernel_cpu_time += time;
  };
  void set_user_cpu_time(unsigned long long time) {
    this->user_cpu_time_last_sched += time;
    this->total_user_cpu_time += time;
  };

  void clear_last_cpu_time() {
    this->kernel_cpu_time_last_sched = 0;
    this->user_cpu_time_last_sched = 0;
  }

  unsigned long long get_cpu_time() {
    return this->kernel_thread ? this->kernel_cpu_time_last_sched
                               : this->user_cpu_time_last_sched;
  }

Os dois primeiros métodos são autoexplicativos, eles incrementam os contadores de tempo locais e globais, do kernel ou do usuário. O terceiro zera o tempo do último escalonamento quando a tarefa é escolhida da fila de tarefas prontas para execução. O último método retorna o tempo de cpu do último escalonamento, diferenciando processos e threads de kernel para que a comparação entre eles seja justa.

Fiz uma pequena alteração na classe Scheduler:

class Scheduler {
...
public:
  virtual void sched(QueueNode<PCB> *);
...
};

Você pode ver que transformei o método sched em virtual, para poder criar uma nova classe derivada:

class FairScheduler : public Scheduler {
public:
  void sched(QueueNode<PCB> *);
};

Afinal, nosso objetivo é única e exclusivamente alterar o método sched, para que ele passe a considerar o tempo de execução da tarefa.

Agora, para declarar o escalonador, basta fazermos assim:

FairScheduler fairSched;
Scheduler *sched = &fairSched;

que o restante do código fica todo intacto! God bless the OOP! E isso se liga ao assunto da VTABLE e tabela de despacho da abertura desse post.

Acabou? Logicamente que não, criança. Vamos ver o que o método sched dessa nova classe faz.

void FairScheduler::sched(QueueNode<PCB> *task) {
  ...
  queue_insert_ordered(this->ready_queue, task, &comparePCB);

  ...
}

Só isso, o resto é código pra ajudar a debugar (você logo vai entender o motivo). Quem faz todo o trabalho sujo é a função queue_insert_ordered. Vamos a ela:

template <class T>
void queue_insert_ordered(QueueNode<T> *&queue, QueueNode<T> *node,
                          int (*compare)(T *, T *)) {
  if (queue == nullptr) {
    queue = node;
    return;
  }

  QueueNode<T> *tmp = queue;
  while (tmp != queue->previous) {
    if (compare(&node->get(), &tmp->get()) < 0) {
      break;
    }
    tmp = tmp->next;
  }

  if (compare(&node->get(), &tmp->get()) < 0) {
    tmp = tmp->previous;
  }

  tmp->next->previous = node;
  node->next = tmp->next;
  tmp->next = node;
  node->previous = tmp;

  if (compare(&node->get(), &queue->get()) < 0) {
    queue = node;
  }
}

Ele é muito parecido com o queue_insert, a diferença é que ele uma uma função de comparação para saber onde inserir o novo elemento. A função é genérica de propósito, afinal, estamos usando templates, e o usuário que a invocar deve passar essa função de comparação como argumento. Na chamada da função, você perceberá que eu passei o endereço de comparePCB. Aqui está essa função:

static int comparePCB(PCB *a, PCB *b) {
  ...
  if (a->get_cpu_time() < b->get_cpu_time()) {
    return -1;
  } else if (a->get_cpu_time() > b->get_cpu_time()) {
    return 1;
  } else {
    return 0;
  }
}

Não é muito diferente das funções compareTo do Javinha.

E como medimos o tempo? A gente cria uma variável de tempo corrente, e funções para iniciar e parar um timer:

unsigned long long curr_time = 0;

...

extern "C" void start_timer() {
  curr_time = get_timer();
  ...
}
extern "C" void stop_kernel_timer() {
  unsigned long long tmp = get_timer();
  unsigned long long diff = tmp - curr_time;
  ...
  current_task->get().set_kernel_cpu_time(diff);
  curr_time = tmp;
  ...
}

extern "C" void stop_user_timer() {
  unsigned long long tmp = get_timer();
  unsigned long long diff = tmp - curr_time;
  current_task->get().set_user_cpu_time(diff);
  curr_time = tmp;
  ...
}

Onde essas funções são chamadas? Nas trocas de contexto (de usuário ou kernel):

...
extern current_task, scheduler, syscall_operations, returning_kernel_entry, start_timer, stop_kernel_timer, stop_user_timer

...

kernel_entry:
    ...
    call stop_user_timer
    ...

    call start_timer
    mov ebx, [syscall_op]
    call [syscall_operations + 4*ebx]

returning_kernel_entry:  
    call stop_kernel_timer
    ...

    call start_timer
    ...
    ret


scheduler_entry:
    ...
    call stop_kernel_timer
    ...
    call scheduler
    ...
    call start_timer
    ...
    ret

Basicamente, paramos e iniciamos os timers dentro dessas funções acima. Um pouco antes de liberar a cpu para a próxima tarefa, também, paramos o timer para que a função sched possa usar o tempo nas comparações.

void do_yield() {
  stop_kernel_timer();
  current_task->get().ready();
  sched->sched(current_task);
  start_timer();
  scheduler_entry();
} 

Por fim, quando uma nova tarefa é escalonada, o escalonador limpa os valores prévios:

extern "C" void scheduler() {
  sched->inc_count();
  current_task = sched->get_ready_task();
  current_task->get().clear_last_cpu_time();
  current_task->get().run();
}

Há outras pequenas atividades que devem ser feitas, que é instanciar o template para usar o PCB, e fazemos isso no arquivo queue-impl-pcb.cpp:

template void queue_insert_ordered(QueueNode<PCB> *&, QueueNode<PCB> *,
                                   int (*)(PCB *, PCB *));

Esse tipo de coisa eu não mais farei nos próximos posts, pois é repetitivo. Só se aparecer algo muito diferente que valha a pena mencionar.

Isso tudo que foi dito até aqui é suficiente para fazer esse escalonador justo, considerando os tempos de execução das tarefas. Só faltou um pequeno detalhe: a função get_timer, invocada pelas funções start_timer, stop_kernel_timer e stop_user_timer acima.

Começando o pesadelo

Retomando a descrição do P2:

Só isso? Oxi, tá fácil hein. Que instrução x86 faz isso? A RDTSC:

Quando mexi com esse trabalho, em 2020, essa parte do código já estava pronto. Confesso que nem me preocupei em como isso era feito. Lembre-se que esses trabalhos são acadêmicos, com o intuito de exercitar conceitos bem específicos. Mexer com temporização no x86 não era um desses conceitos, e vinha pronto no código fornecido para nós.

Então, chumbei a instrução rdtsc na minha função get_timer. Note também que os códigos que usam essa função já retornam para variáveis unsigned long long. A instrução rdtsc coloca os valores nos registradores edx:eax, mas o compilador é inteligente o suficiente para trabalhar bem com esses valores de 64bit. Então tudo certo!

Será mesmo? Bom, quando comecei a mexer com essa parte, os valores que retornavam eram malucos. Pior, quando chamava a rdtsc na sequência, na vã esperança de retornar valores compatíveis, minha sanidade começou a esvair pelo ralo.

A partir de agora, o que virá é um relato de várias tentativas para tentar entender o que estava acontecendo. Não consigo afirmar com certeza qual alteração foi efetiva, ou mesmo se alguma outra coisa deveria ter sido feita. Mas pelo menos cheguei em uma resposta “plausível”. Vamos lá.

Sistema de virtualização

Começo o primeiro post (VEJA AQUI) avisando que não usaria o emulador Bochs, mas sim o QEMU. Mais do que isso, rodo o QEMU direto no meu Ubuntu, que roda no meu WSL2 no meu Windows 11. Percebe onde quero chegar?

Estávamos chamando o QEMU assim:

/usr/bin/qemu-system-i386 -machine accel=kvm ... -cpu host ...

Isso estava fazendo o QEMU rodar direto na CPU virtualizado pelo KVM, usando como CPU o processador do meu host. Isso significa que ele estava pegando os valores do timestamp do meu CPU, que está rodando diversas outras coisas, como o próprio QEMU, VSCode, WSL, Windows, Red Dead Redemp…. ops, esse não. Pior, os valores não eram consistentes entre as chamadas, pois é provável que o processo do QEMU esteja executando em CPUs diferentes, que possuem timestamps diferentes.

Então, a primeira alteração foi alterar o método de aceleração para uma emulação embutida no QEMU, e dizer que estamos usando apenas uma CPU:

/usr/bin/qemu-system-i386 -smp cpus=1 -machine accel=tcg ...

Resolvido? Não. Volte um pouco e veja a citação do P2, que diz que a get_timer retorna o número de instruções que foram executadas desde o boot. Só que os números que a rdtsc continuavam não fazendo sentido. Ao executar duas rdtsc na sequência, deveria vir apenas 1 de diferença para o valor anterior. Ok, 2, 3, no máximo 5 instruções, considerando uma arquitetura superescalar em que há pipelines e execuções fora de ordem, mas não deveria ser muito diferente disso. O problema é que o valor retornado girava na casa de 70 mil!

Diferenças de TSC entre processadores

Se você for na página da wikipedia sobre as instruções x86 encontrará o seguinte:

Então, antigamente o TSC era incrementado de 1 mesmo, o que era previsto pelo trabalho. Mas agora, processadores mais modernos não são mais assim. Mais do que isso, aquela nota de rodapé [m] da imagem acima diz:

Bom, diante disso, assumi que o valor era incrementado, e de alguma forma era proporcional ao número de instruções executadas, mesmo sem saber exatamente quando. E ai começou o segundo problema.

O compilador também não colabora!

Observe o código abaixo:

void thread1() {
  int x = 0;
  for (int i = 0; i < 10000; i++) {
    x += i * 2;
  }
  printk("t1 10000 x=%d\n", x);
  printk("t1 sleeping 10 second\n");
  do_yield();
  printk("t1 exiting\n");
  do_exit();
}

Meu objetivo ai em cima é só fazer o processador gastar tempo calculando nada. Outras threads tinham um código parecido, mas variando o valor de i. Ao executar o código, as threads levavam quase o mesmo tempo, independente do valor do laço for. Era hora de invocar o gdb e verificar o que estava acontecendo.

O problema é que o compilar é muito mais inteligente que eu (não é muito difícil, mas enfim). O compilador vê um código desse e pensa: “poxa, mas eu consigo calcular isso ai de antemão, o código dele não precisa iterar nesse laço NEM UMA ÚNICA VEZ!". E ele está certo. Só que agora eu não quero eficiência e otimização, eu estou testando a temporização das threads, caraca! Bom, isso nem é tão difícil assim de resolver, basta enfiar um volatile (volatile int x = 0;) que o compilador é forçado a ler o valor da memória e assim, iterar no loop. Percebe-se que coisas difíceis não são fáceis.

Mesmo corrigindo o código acima, a execução não estava satisfatória. Precisei apelar: até o momento, eu não havia consultado nenhuma vez o código original. Mas estava chegando em um beco sem saída. Afinal, o que o código original que eu tinha acesso faz?1

E o meu código estava assim (arquivo util.h):

#include <x86intrin.h>

...

inline unsigned long long get_timer() {
  ...
  return __rdtsc();
};

A tradução dos dois códigos resulta na mesma coisa, a instrução rdtsc em x86. Aproveitei e vi a função delay do arquivo deles:

E o que é esse MHZ ai?

Ahá, tem um valor chumbado no código. Eles prepararam esse código para as máquinas do laboratório fishbowl de Princeton. Esse valor não bate com nosso ambiente de desenvolvimento.

Nesse momento, eu troquei aquele código de loop e copiei essa função de delay. E fiquei testando valores de MHZ para ver se conseguia gerar um delay de uns 10 segundos.

Quando não obtive sucesso, o próximo passo foi apelar.

Usando o Bochs

Cansado de apanhar da vida e de todos, resolvi usar o Bochs para comparar as diferenças entre os dois. Primeiro, instalei o Bochs via apt-get:

sudo apt-get install bochs bochsbios vgabios bochs-x

Na minha distro, ele instalou a versão 2.7 do Bochs.

Depois, criei o arquivo ./util/bochsrc abaixo.

megs: 16
#needs package bochsbios
romimage: file=/usr/share/bochs/BIOS-bochs-legacy
#needs package vgabios
vgaromimage: file=/usr/share/bochs/VGABIOS-lgpl-latest
vga: extension=vbe
floppya: 1_44=./build/boringos.img, status=inserted
boot: floppy
log: /tmp/bochsout.txt
mouse: enabled=0
cpu: count=1, ips=1000000, reset_on_triple_fault=1
#vga_update_interval: 150000
#i440fxsupport: enabled=1
#needs package bochs-x
display_library: x
log: /dev/null
magic_break: enabled=1

Agora, basta comentar a linha que chama o QEMU para chamar o Bochs:

#!/bin/sh -ex
...

CURRDIR=`pwd`

#/usr/bin/qemu-system-i386 ...
bochs -q -f $CURRDIR/util/bochsrc

Ao executar o arquivo ./util/VM_BoringOS.sh, recebi o erro bx_dbg_read_linear: physical memory read error (phy=0x000100000000, lin=0x0000000100000000). Os endereços de memória não eram esses, mas o erro era. Depois de muito pesquisar, a sugestão foi instalar a versão 2.8. Ough. Lá vai:

wget https://github.com/bochs-emu/Bochs/archive/refs/tags/REL_2_8_FINAL.tar.gz
mv REL_2_8_FINAL.tar.gz bochs_2_8.tar.gz
tar -zxvf bochs_2_8.tar.gz
cd Bochs-REL_2_8_FINAL/bochs/
./configure --with-all-libs -enable-plugins --enable-debugger --enable-smp --enable-x86-debugger
make
sudo make install

No fim das contas, consegui executar meu kernel no Bochs. De cara descobri que:

1. A diferença entre dois timestamps do rdtsc gira em torno de 3, 4 ou 5 instruções

2. Havia um erro no meu código do delay, estava unsigned long long deadline = millis * 1000 * MHZ; quando deveria ser unsigned long long deadline = get_timer() + (millis * 1000 * MHZ);.

Com essas constatações e correções, planejei o seguinte código para testes do escalonador justo. O arquivo tasks.cpp:

...
void thread1() {
  printk("t1 sleeping 10 second\n");
  delay(10000);
  do_yield();
  printk("t1 exiting\n");
  do_exit();
}

void thread2() {
  printk("t2 sleeping 1 second\n");
  delay(1000);
  do_yield();
  printk("t2 exiting\n");
  do_exit();
}

void thread3() {
  printk("t3 sleeping 4 second\n");
  delay(4000);
  do_yield();
  printk("t3 exiting\n");
  do_exit();
}

void thread4() {
  printk("t4 sleeping 2 second\n");
  delay(2000);
  do_yield();
  printk("t4 exiting\n");
  do_exit();
}

E o process1.cpp:

...

int main() {
  set_display_position(20, 0);
  printk("p1 sleeping 0.5 second\n");
  delay(500);
  yield();
  printk("p1 exiting\n");
  return 0;
}

Os processos são adicionados na ordem listada, então a thread1 é o PID 0, thread2 é o PID 1, até o processo 1 que tem PID 4. Todos começam com tempo de cpu 0, que vai mudando conforme a tarefa vai fazendo yield e vai sendo reinserida na lista de tarefas prontas. A ordem de execução dos PIDs deve ser então: 0, 1, 2, 3, 4, (neste momento, todas as tarefas já executaram um pouco e foram reinseridas na fila), 4, 1, 3, 2, 0. A cada reinserção da tarefa na fila, para debugar, pedi para imprimir o nó, com o PID e seu tempo de cpu. E, voilá, é isso que temos:

Perfeito. Depois disso, fiquei ajustando o valor do MHZ e cronometrando a execução. Como é esperado que t1 execute por 10 segundos, cheguei no valor de 85 MHZ para o Bochs.

Executando o mesmo código no QEMU, com esse mesmo valor de 85 MHZ, o resultado em termos de valores apresentados são muito próximos no quesito ordem de grandeza, confira:

Mas a execução é quase imediata, t1 não leva 10 segundos. Tentei alterar o MHZ e cronometrar, mas a tarefa foi infrutífera. Além de não conseguir chegar a um valor factível, por algum motivo a ordem das tarefas foi alterada, o que não faz sentido. Parece que para o QEMU, ainda falta configurações que eu ainda não estou ciente. Faz parte, não dá pra ganhar todas.

Como de praxe, o código para esta parte do nosso trabalho está no meu github.

No fringir dos ovos…

A gente acabou esse post com mais perguntas do que respostas. Mas é assim que a gente aprende no fim das contas. Se você não acredita no tamanho da encrenca dessa instrução rdtsc, veja essa galera do SUSE analisando isolamento de CPU no kernel do Linux.

Mas chega de P2! Nos próximos posts vamos começar o P3 e nosso kernel preemptivo! Minha esperança é que usando o PIT nós consigamos detectar a velocidade da CPU, talvez usando o HPET. Mas não conte com isso, não prometo nada :D

Anterior

Próximo

Esse P2 não acaba, hein? Enquanto no último post tratamos de primitivas de sincronização para as threads, agora vamos adentrar em uma área que praticamente todos nós lidamos diariamente: Processos e Modo Usuário.

Quer dizer, mais ou menos. Fazer isso de modo completo exigiria interrupções, paginação e mudança de permissões do processador, e não temos nenhuma das duas ainda. Não por negligência ou desleixo, uma parte disso será feita no próximo trabalho. Mas se não temos nada disso, como podemos falar em Modo Usuário?

Vamos ver o que é pedido no P2 sobre isso:

Então, para esse trabalho, um processo não é muito diferente de uma thread. O processo será compilado de forma “autônoma”. Não temos nada de interrupções, então não temos o conceito de carregar o executável do disco. O que vamos fazer é definir os endereços de entrypoint dos processos, e alterar o utilitário createimage para “colá-los” na imagem do kernel.

A beleza da coisa é que, tanto na ida quanto na volta, a única informação que o kernel tem do executável do processo é o seu entrypoint. E de forma similar, o processo só conhece um ponto de entrada para o kernel, que no trabalho eles chamaram de chamada de sistema.

Nesse trabalho, no momento, temos as quatro threads do post anterior e adicionaremos dois processos. O layout da memória ficará assim:

O createimage espera receber agora os executáveis do bootloader, kernel e processos, ordenados pelo entrypoint, conforme imagem acima. A imagem é então muito maior do que o código efetivo; isso porque o createimage inserirá padding do fim do kernel até o início do processo 1, do fim do processo 1 até o início do processo 2 e assim por diante.

O createimage acabou ficando mais simples, já que ele corre o argumento do argv lendo o ELF e juntando tudo. Segue um trecho do arquivo alterado, e se quiser ver completo, visite meu github:

...

int main(int argc, char *argv[]) {
  bool extended = false;
  std::ostringstream output_string;
  std::vector<u_int8_t> bytearray;
  int image_counter = 0;
  for (int c = 1; c < argc; c++) {
    std::string arg = std::string(argv[c]);
    if (arg.compare("--extended") == 0) {
      extended = true;
    } else {
      std::ifstream exec_if(arg, std::ios::binary);
      if (exec_if.fail()) {
        std::cerr << "Error: Can't open ELF file: " << arg << std::endl;
        return 1;
      }

      std::vector<Elf32_Phdr> exec_hs = read_exec_file(exec_if);
      extract_segments(arg, exec_hs, exec_if, output_string, bytearray);

      exec_if.close();
    }
  }

...

Depois, escrevemos os processos. Segue o process1.cpp:

#include "include/syslib.h"
#include "include/util.h"

class Test {

public:
  int x;
  Test() : x{15} {};
};

Test y;

int main() {
  set_display_position(20, 0);
  Test t;
  printk("Hello World! t.x %d - ", t.x);
  printk("Hello World! y.x %d - ", y.x);
  t.x = t.x + 100 + y.x;
  printk("Hello World! t.x %d\n", t.x);
  printk("process1 is yielding\n");
  yield();
  printk("process1 woke up and is exiting...\n");
  return 0;
}

E o process2.cpp:

#include "include/syslib.h"
#include "include/util.h"

int main() {
  set_display_position(23, 0);
  printk("process2 ");
  int i = 0;
  while (i++ < 15000) {
    set_display_position(23, 9);
    printk("%d", i);
    yield();
  }
  printk("\nprocess2 finished!");
  return 0;
}

Se você é perspicaz (e você é, e eu também, como diria o Cortella), percebeu duas coisas nos códigos acima: 1) usamos a função main como função principal; e 2) há a invocação da syscall yield, mas não da exit. Pode isso, Arnaldo?

Pois é, isso não está no P2, mas como estou usando C++ em tudo, me perguntei se conseguiria usar classes, ver se os construtores estão funcionando etc. Obviamente, quando comecei a fazer percebi que não estavam :D mas consegui preparar o código até que isso fosse viável. “E como você fez isso?”, você me pergunta. Ótima pergunta, aliás.

Bom, na real não é muito diferente de como fizemos no kernel. Temos que envolver os códigos objetos dos processos nos nossos velhos conhecidos crti.o crtbeg.o <OBJETO> crtend.o crtn.o. Assim conseguimos invocar as funções _init e _fini, que, você já sabe, invoca os construtores e destrutores. Mas quem invoca essas funções?

Ah, essa é a beleza da coisa. Enquanto, no caso do kernel, nosso próprio kernel É o entry point e deve chamar tais funções, agora cada processo deve ter um processo de inicialização, mas que ainda assim, seja transparente para ele, como é nos códigos acima.

E com isso, criei o crt0.cpp:

#include "include/syslib.h"
#include "include/util.h"

extern int main();

extern "C" void _start() {
  _init();
  main();
  _fini();
  exit();
}

Você viu a beleza da coisa? Você percebe como a natureza é maravilhosa? Quando Deus desenhou o processador, ele estava namorando (já no caso do x86, ele estava de ressaca com certeza, mas isso não vem ao caso). Esse é o nosso verdadeiro entrypoint, chama o construtor, chama a main (função externa à unidade de compilação crt0.cpp, afinal, a main está nos arquivos process1.cpp e process2.cpp). Ele finaliza executando a lista de destrutores na função _fini, e por fim, chama a syscall exit. Perfeito!

Para você entender como isso é montado no Makefile, veja abaixo um exemplo para o process1.cpp. É igual para o process2.cpp e demais processos que venham a surgir.

...
UOBJS:=syslib.o util.o screen.o

CRTI_OBJ=crti.o
CRTBEGIN_OBJ:=$(shell g++ -m32 $(CFLAGS) -print-file-name=crtbegin.o)
CRTEND_OBJ:=$(shell g++ -m32 $(CFLAGS) -print-file-name=crtend.o)
CRTN_OBJ=crtn.o

...
UOBJ_LINK_LIST_BEG:=crt0.o  $(CRTI_OBJ) $(CRTBEGIN_OBJ) 
UOBJ_LINK_LIST_END:=$(UOBJS) $(CRTEND_OBJ) $(CRTN_OBJ)

...

process1: $(UOBJ_LINK_LIST_BEG) process1.o $(UOBJ_LINK_LIST_END)
	cd $(OUTPUTDIR) && ld -O2 -g -m elf_i386 -T../linker.ld -Ttext 0x10000 -z noexecstack -o $@ $(UOBJ_LINK_LIST_BEG) process1.o $(UOBJ_LINK_LIST_END)

Usamos o mesmo arquivo do linker do kernel (-T../linker.ld), definimos o entrypoint do processo (-Ttext 0x10000), e envolvemos o código objeto do processo com os outros códigos objetos $(UOBJ_LINK_LIST_BEG) process1.o $(UOBJ_LINK_LIST_END). Ao executar o comando make, essa linha resulta em:

cd build && ld -O2 -g -m elf_i386 -T../linker.ld -Ttext 0x10000 -z noexecstack -o process1 crt0.o  crti.o /usr/lib/gcc/x86_64-linux-gnu/11/32/crtbegin.o  process1.o syslib.o util.o screen.o /usr/lib/gcc/x86_64-linux-gnu/11/32/crtend.o crtn.o

E os UOBJS? Bom, util.o e screen.o são exatamente os mesmos do kernel, eles escrevem no endereço 0xB8000, ou seja, a memória de vídeo. Mas tive que alterar e voltar a posição do cursor e cores para variáveis globais no arquivo screen.o. Isso porque antes eu tinha colocado no PCB (cada thread/processo teria sua própria posição e cores), mas o processo não tem informação nenhuma do kernel, e isso inclui o PCB… Precisei voltar a como estava. O screen.cpp agora está assim:

#include "include/screen.h"

static DisplayChar *video_memory = (DisplayChar *)SCREEN_ADDR;

static int display_position = 0;
static char current_color = (GRAY & 0x0f) | (BLACK << 4);
...

Mas há uma consequência nisso. No código do kernel, há um screen.o ligado. Mas agora há um screen.o ligado ao process1.o e outro ao process2.o. Significa que as threads do kernel compartilham essas variáveis globais, mas cada processo tem suas próprias variáveis.

E o que tem em syslib.cpp? Vejamos:

#define SYSCALL_YIELD 0
#define SYSCALL_EXIT 1

#include "include/util.h"

void (**kernel_entry_point)(int) = (void (**)(int))0x00F00;

void yield() { (**kernel_entry_point)(SYSCALL_YIELD); }

void exit() { (**kernel_entry_point)(SYSCALL_EXIT); }

MEU DEUS QUE CÓDIGO PROFANO É ESSE? Você é muito previsível, se acalme que eu já explico. Vamos ver o que o P2 fala sobre syscalls:

Lembre-se da imagem acima:

A única coisa que os processos sabem sobre a memória é isso ai, o endereço do entrypoint para o kernel. Mas se você é esperto (e você é, e eu também), sabe que quando o _start do kernel é invocado, não tem nada útil nesse endereço. Afinal, o bootloader joga o kernel a partir do endereço 0x1000, que é maior que 0xf00. Acontece que a própria _start acessa o endereço 0xf00 e coloca um outro endereço nessa memória, que é o endereço da função kernel_entry!

...
#define USER_ENTRY_POINT 0x00F00
...

extern "C" void _start() {
...
  *(uint32_t *)(USER_ENTRY_POINT) = (uint32_t)&kernel_entry;
...

Ou seja, a posição 0x00f00 é um ponteiro para um ponteiro de função, e a função é a kernel_entry. Por isso, os dois ** na declaração:

void (**kernel_entry_point)(int) = (void (**)(int))0x00F00;

Se você é meio burro (e você é, e eu também), talvez a imagem abaixo facilite o entendimento:

Depois nós vemos certinho como (**kernel_entry_point)(SYSCALL_YIELD) e (**kernel_entry_point)(SYSCALL_EXIT) são executadas. Antes disso, vamos ver o que é necessário alterar no PCB para comportar a execução de processos.

E:

Então, nós salvávamos o contexto na scheduler_entry para as threads, e agora precisamos salvar logo após entrar em kernel_entry também. Apesar que isso não é obrigatório NESTE trabalho, porque:

Mas estou construindo este kernel baseado em um trabalho escolar. No próximo trabalho, quando interrupções de software estiverem habilitadas, uma chamada do sistema do usuário poderá ser interrompida. Então, vai por mim, é melhor já deixar isso pronto agora.

Não há grandes alterações no PCB, a gente reserva espaço para salvar o contexto do usuário:

...

class PCB {
  uint32_t kregs[9]; // EDI, ESI, EBP, original ESP, EBX, EDX, ECX, EAX, EFLAGS
                     // (KERNEL MODE)
  uint32_t uregs[9]; // EDI, ESI, EBP, original ESP, EBX, EDX, ECX, EAX, EFLAGS
                     // (USER MODE)
...

E agora, a parte delicada do trabalho, feito em assembly. Vamos adentrar no covil da kernel_entry. E, de novo, depois de pronto, parece fácil, mas perdi um tempão tentando depurar um problema de estouro de pilha. Se a pilha não for restaurada corretamente entre as chamadas e salvamento de contexto, qualquer laço de 10, 15 mil iterações que chamem troca de contexto, usando yield por exemplo, com pilhas de tamanho 4KB, o estouro de pilha vem e você nem percebe.

O fluxo de chamadas segue então a imagem abaixo:

Enquanto as threads de kernel tem acesso direto a função do_yield, o processo precisa fazer a chamada de sistema yield, que invoca a kernel_entry, e esta é responsável por invocar as funções de kernel, no caso, a do_yield.

Mas e agora, como se faz para salvar o contexto e restaurar o próximo? Aqui as coisas começam a ficar interessantes. Para as threads de kernel, nada é alterado, isso já está funcionando. Para os processo ao entrar na função kernel_entry, estamos no contexto do usuário, com a pilha do usuário. Devemos nesse momento chavear para as pilhas (e registradores) de kernel (em nome desse processo. Não das outras tarefas do kernel). Nisso, a chamada de sistema chamará ou a do_yield ou do_exit. Essas funções, você já viu: elas invocarão a scheduler_entry, e essa função salva o contexto de kernel do processo. Nisso, o escalonador escolhe outra tarefa, restaurando seu contexto de kernel. Caso essa tarefa seja um processo, significa que ele obrigatoriamente chegou até aqui via kernel_entry. Portanto, salvamos novamente o contexto de kernel do processo, e restauramos o contexto de usuário, e retornamos da chamada de sistema. Ufa!

Confuso? Talvez uma imagem ajude a ilustrar melhor. Essa parte é enjoada mesmo, leve seu tempo para entender o que está acontecendo.

O fluxo preto é de quando um processo de executando, enquanto o laranja é de uma thread de kernel. Ao passar pelo escalonador, uma nova tarefa é escolhida, e pode ser uma thread o kernel ou um processo, seguindo pela mesma ideia das cores. O que está em vermelho são funções/etapas que ocorrem dentro do kernel.

Antes de apresentar a tenebrosa kernel_entry, vamos refletir sobre uma coisa: temos um ponto de entrada único, mas diversos serviços (yield, exit e o que mais surgir). Ao observar novamente o arquivo syslib.cpp:

void yield() { (**kernel_entry_point)(SYSCALL_YIELD); }

void exit() { (**kernel_entry_point)(SYSCALL_EXIT); }

Perceba que é a mesma função, o que muda é o argumento dela, o que faz sentido pelo design que estamos analisando. Dentro da função kernel_entry, então, ele deve “selecionar” a função correta de acordo com o parâmetro informado pelo chamador. Se tratarmos esse “parâmetro” como um índice em um vetor de ponteiros para função, nossos problemas estão resolvidos (por enquanto). Assim, eu criei o seguinte vetor no arquivo scheduler.cpp:

void (*syscall_operations[])() = {&do_yield, &do_exit};

Pronto, temos um array de ponteiros de função, com as funções que “servimos” ao processo. Se o processo chamar o kernel_entry com o valor 0, ele invocará a do_yield. Se for 1, será do_exit, e assim por diante.

Após muito enrolar, vamos olhar a kernel_entry, que está no arquivo entry.asm. Como eu fiz algumas mudanças na scheduler_entry para parametrizá-la melhor, vou mostrar o arquivo inteiro.

global scheduler_entry, kernel_entry
extern current_task, scheduler, syscall_operations, returning_kernel_entry

%define ESP_OFFSET (3*4)
%define K_REGS_LIMIT (9*4)
%define U_REGS_LIMIT (18*4)
%define ESP_OFFSET_FROM_LIMIT (6*4)

syscall_op dd 0
old_esp dd 0

kernel_entry:
    push ebp
    mov ebp, esp
    mov esp, [current_task]
    lea esp, [esp + U_REGS_LIMIT]
    pushfd
    pushad
    mov [esp + ESP_OFFSET], ebp

    mov ebx, [ebp+8]
    mov [syscall_op], ebx

    mov esp, [current_task]
    popad
    popfd
    mov esp, [esp - ESP_OFFSET_FROM_LIMIT]

    mov ebx, [syscall_op]
    call [syscall_operations + 4*ebx]

returning_kernel_entry:  
    mov [old_esp], esp
    mov esp, [current_task]
    lea esp, [esp + K_REGS_LIMIT]
    pushfd
    pushad
    mov ebx, [old_esp]
    mov [esp + ESP_OFFSET], ebx  

    mov esp, [current_task]
    lea esp, [esp + K_REGS_LIMIT]    
    popad
    popfd
    mov esp, [esp - ESP_OFFSET_FROM_LIMIT]

    pop ebp
    ret


scheduler_entry:
    push ebp
    mov ebp, esp
    mov esp, [current_task]
    lea esp, [esp + K_REGS_LIMIT]
    pushfd
    pushad
    mov [esp + ESP_OFFSET], ebp
    mov esp, ebp
    call scheduler
    mov esp, [current_task]
    popad
    popfd
    mov esp, [esp - ESP_OFFSET_FROM_LIMIT]
    pop ebp
    ret

O segredo todo, assim como foi com a scheduler_entry, é posicionar o registrador esp na posição certa do PCB para poder fazer os pushs e pops do lugar certo. A função começa salvando o contexto de usuário:

    push ebp
    mov ebp, esp
    mov esp, [current_task]
    lea esp, [esp + U_REGS_LIMIT]
    pushfd
    pushad
    mov [esp + ESP_OFFSET], ebp

Depois, como vamos chaver o contexto, precisamos salvar o parâmetro que passaram ao chamar a kernel_entry. Lembra-se que a chamamos passando um argumento, que é o serviço a ser executado? Então. Esse parâmetro está na pilha do contexto do usuário, e como esse contexto vai mudar, já que vamos chaver para o contexto de kernel desse processo, precisamos salvá-lo antes:

    mov ebx, [ebp+8]
    mov [syscall_op], ebx

Ok, o parâmetro foi salvo na variável syscall_op. Agora a gente restaura o contexto de kernel do processo:

    mov esp, [current_task]
    popad
    popfd
    mov esp, [esp - ESP_OFFSET_FROM_LIMIT]

Estamos no contexto do kernel do processo. Só falta chamar o serviço desejado. Basta recuperar o valor de syscall_op e usá-lo como índice no array syscall_operations:

    mov ebx, [syscall_op]
    call [syscall_operations + 4*ebx]

Show de bola! Isso chamará a do_yield e do_exit, que chamará a scheduler_entry… You know the drill. Possivelmente, esse processo será posto pra dormir (mas lembre-se que ele está no contexto de kernel do processo). Quaaaaando esse processo for acordado, ele irá ir retornando das chamadas, e retornando da do_yield (se fosse do_exit, esse processo não retornaria mais, não é mesmo? :D ), ele continuará logo após call [syscall_operations + 4*ebx]. E o que a gente precisa fazer agora?

Bom, todo o serviço do contexto de kernel para esse processo foi feito. Agora, a gente salva esse contexto:

    mov [old_esp], esp
    mov esp, [current_task]
    lea esp, [esp + K_REGS_LIMIT]
    pushfd
    pushad
    mov ebx, [old_esp]
    mov [esp + ESP_OFFSET], ebx  

Perceba que, como precisamos alterar o valor de esp para fazer o procedimento, a gente salva ele provisoriamente em old_esp para salvar o valor correto também.

Depois disso, a gente só restaura o contexto do usuário:

    mov esp, [current_task]
    lea esp, [esp + K_REGS_LIMIT]    
    popad
    popfd
    mov esp, [esp - ESP_OFFSET_FROM_LIMIT]

    pop ebp
    ret

E ao fim do código acima, ele já restaura a pilha e retorna para quem chamou yield.

Pera lá um pouquinho! Você acha que me engana? Muito suspeito aquela declaração returning_kernel_entry no meio da função kernel_entry! O que ela faz?

Então jovem, como sempre eu mostrei o caminho feliz. Mas a vida é uma caixinha de surpresas, não é esse algodão-doce que você está pensando ai não! Temos um corner case importante que não tratamos ainda: o primeiro escalonamento para execução do processo.

Pense no seguinte: o PCB do processo está na fila de tarefas prontas. Quando o processo é escolhido pelo escalonador, quem fez isso foi a scheduler_entry, que invoca o scheduler, lembra?

Significa que estamos no contexto de kernel do processo, mas nosso entrypoint está no contexto de usuário! Como pulamos para lá?

Usamos da boa e velha gambiarra! O que fazemos é enganar o processo, e não vamos colocar o entrypoint do processo diretamente para execução, vamos fingir que estamos retornando de uma chamada do sistema, para ele ir restaurando o contexto necessá rerio e acabar no entrypoint do processo mas no contexto de usuário! E pra fazer isso é bem fácil na real (depois que você sabe o que fazer), fazemos uma pequena alteração no método config da classe PCB:

void PCB::config(int pcb_index, void (*entry_point)(), uint32_t pid,
                 bool kernel_thread) {
  this->pid = pid;
  this->kernel_thread = kernel_thread;
  uint32_t stack = START_STACKS_ADDRESS + 2 * pcb_index * STACK_SIZE;
  if (stack > STACK_MAX) {
    panic("Stack overflow\n");
  }
  this->kregs[3] = stack - 8;
  this->kregs[2] = *(uint32_t *)(stack - 8) = stack;
  *(uint32_t *)(stack - 4) =
      kernel_thread ? (uint32_t)entry_point : (uint32_t)&returning_kernel_entry;
...

  if (!kernel_thread) {
    stack += STACK_SIZE;
    if (stack > STACK_MAX) {
      panic("Stack overflow\n");
    }
    this->uregs[3] = stack - 8;
    this->uregs[2] = *(uint32_t *)(stack - 8) = stack;
    *(uint32_t *)(stack - 4) = (uint32_t)entry_point;
  }
  this->status = READY;
}

Reservamos duas pilhas para o PCB, independente se for uma kernel thread ou processo. Para kernel threads, esse espaço adicional é desperdiçado, mas como são 9 registradores de 4 bytes, estou ok em desperdiçar 36 bytes nesse caso.

Note contudo que fazemos um teste para definir o entrypoint: se for uma thread kernel, nada muda, informamos o entrypoint da thread. Se for um processo, ai informamos o endereço de returning_kernel_entry. Isso porque quando o scheduler_entry terminar, ele vai fazer um ret para esse endereço. O que a returning_kernel_entry faz dali pra frente é restaurar o contexto do usuário e ele vai retornar. Para onde? Agora sim, para o entry_point do processo.

Novamente, usamos o funcionamento de pilhas do x86 para que ele faça o trabalho sujo todo para nós. Ardiloso!

E como ficou o resultado? Olha ai jovem.

E como você já sabe, para conferir o código até esse ponto, visite meu github.

Anterior

Próximo

Depois do post anterior, é hora de dar uma respirada para apaziguar os ânimos (autocrítica). Do ponto que estamos, acredito que a parte mais fácil é agora implementar o lock que as threads usarão, como exigido pelo P2. Mas afinal, o que é para ser feito? Na página do P2 é solicitado:

Certo, antes de entrar nos meandros, vale fazer uma breve recapitulação. Longe de querer que esse post seja uma referência em sistemas concorrentes, ele não é, há milhares de outros materiais melhores para isso. Mas para garantirmos estar na mesma página nessa discussão, é válido estabelecer alguns pontos.

Temos várias tarefas concorrentes executando no mesmo processador e, por enquanto, acessando a mesma área de endereçamento na memória. Em especial as threads de kernel, elas acessam podem acessar as mesmas variáveis, e devido ao comportamento aleatório que as tarefas executam, a ordem das operações pode alterar o resultado.

Pior, em sistemas verdadeiramente preemptivos (não é o nosso caso. AINDA), é possível que uma tarefa seja interrompida bem no momento do acesso a uma área importante da memória, mas o dado já foi lido para o registrador. A outra tarefa pode manipular essa região de memória, e ao retornar para a tarefa anterior, ela está com um valor desatualizado no registrador e irá processar informações de forma errada.

Acredite em mim, fazer depuração em sistemas concorrentes é um pesadelo, pois é pouco provável que tenhamos algum controle sobre o escalonamento das tarefas, que é feito pelo Sistema Operacional.

Mesmo que aqui NÓS somos o Sistema Operacional (Yay!), ainda assim é uma tarefa difícil, pois em teoria o algoritmo de escalonamento está certo. O que pode estar errado é a forma como você programou suas threads, de forma que elas acessam a memória compartilhada entre elas de forma anárquica.

E olha que legal, mesmo estando trabalhando com um kernel não preemptivo neste post, ainda assim precisamos de primitiva de sincronização para podermos forçar determinada ordem de execução das threads.

A forma como você implementa exclusão mútua para evitar condições de corrida no kernel do Linux, por exemplo, dependem de quanto tempo você vai passar na região crítica. Para curtíssimos tempos, um spinlock é suficiente. Se você levar um tempo considerável, talvez seja interessante bloquear a thread e colocá-la para dormir, até que o lock seja resolvido.

Vamos retomar alguns conceitos primeiro. Não seremos aderentes a conceitos e nomenclaturas científicas, esse não é o objetivo. O objetivo aqui é dar uma ideia do problema e como podemos resolver para o nosso caso, e talvez conhecer alguns outros mais.

Região Crítica

A região crítica é aquela parte do código ou área de memória em que devem ser acessadas exclusivamente, em um determinado tempo, por uma tarefa, e somente por ela. É uma arte definir exatamente as regiões críticas de um código e sua extensão, pois se mais de uma tarefa está tentando acessar a região crítica, se ela for longa demais, as outras tarefas vão ficar esperando.

No livro Linux Kernel Development, Robert Love é claro em dizer que você deve proteger os dados (áreas de memória compartilhada) e não os fluxos de execução, ou seja, seu código. Tenha isso em mente ao projetar as regiões críticas de seu código

Condição de Corrida

Se mais de uma thread conseguir acessar uma região crítica, elas estarão em condição de corrida. Desse ponto em diante, é difícil prever o comportamento das tarefas, afinal, elas não deveriam conseguir acessar a região crítica ao mesmo tempo. É seguro dizer que se duas tarefas estão em condição de corrida, o comportamento delas será indeterminado. Fuja de condições de corrida como o diabo foge da cruz!

Exclusão Mútua

Exclusão mútua são as premissas e propriedades que você deve garantir para que duas tarefas não entrem em condição de corrida em uma região crítica. Para quem é de banco de dados, lembrará do ACID e de serialização de transações conflitantes, exatamente para evitar que elas rodem ao mesmo tempo.

E eu com isso?

Como dito anteriormente, há algumas formas de se implementar exclusão mútua, e em geral isso depende de suporte do hardware.

Desabilitar interrupções

Para sistemas preemptivos que são interrompidos pelo PIT (Programmable interval timer), o código abaixo pode funcionar (contém pegadinha):

    cli
    mov eax, [critical_region]
    inc eax
    mov [critical_region], eax
    sti

O código acima recupera um valor da memória, incrementa-o e devolve para a memória. Ao desabilitar as interrupções (e reabilitar logo em seguida), garantimos que o PIT não nos incomodará e esse código executará completamente nesse processador…

… nesse processador é importante, porque esse é justamente o problema desse código. As instruções cli/sti só desabilitam as interrupções para o processador em que esse código está executando. Nada impede que outro processador acesse [critical_region] nesse momento, e ai sua exclusão mútua não é garantida.

Claro que há casos de uso disso. Há estruturas de dados que notadamente são acessíveis apenas por um processador e nesses casos, essa solução funciona bem.

No nosso caso, sinto dizer, isso não vai funcionar. Estamos usando apenas um processador, ok, mas as interrupções já estão desabilitadas, e não as reativaremos enquanto não instalarmos o ISR (Interruption Service Routine), que só acontecerá no próximo trabalho. No nosso caso, a tarefa adquire o lock para entrar na região crítica e cede o processador no meio do processo. Desabilitar interrupções em um kernel não preemptivo não muda nada no fim das contas.

Operações atômicas

Se você notou bem, o problema todo do exemplo anterior é porque a operação toda na verdade levou três instruções: uma para trazer o dado da memória para o registrador, outra para incrementar o registrador e a última para devolver o dado para a memória. Se houvesse uma forma de fazer tudo isso de uma vez de forma garantida, já teríamos meio caminho andado.

De forma conceitual, há previsão de que o hardware forneça algum tipo de instrução Test and Set. Essa instrução deve setar o valor da memória, em geral para o valor 1, e devolve o valor antigo. E como isso é útil para garantir a Exclusão Mútua, você me pergunta? Bom, podemos implementar um Spinlock com isso.

Spinlock

A utilíssima página do OSDev tem um exemplo bem legal de um Spinlock, que chupinharei (afinal eu estou dando os devidos créditos). Lá vai:

#include <stdatomic.h>

void acquire_mutex(atomic_flag* mutex)
{
	while(atomic_flag_test_and_set(mutex))
	{
		__builtin_ia32_pause();
	}
}

void release_mutex(atomic_flag* mutex)
{
	atomic_flag_clear(mutex);
}

E como isso funciona? Bom, partiremos da premissa que o mutex é um valor booleano inicialmente definido como falso.

A primeira tarefa tentará adquirir o lock, invocando a função acquire_mutex. Essa, por sua vez, chama a função atomic_flag_test_and_set, que define o novo valor de mutex para verdadeiro, e retorna o valor antigo (falso). Com falso, o loop while nem inicia. Pronto, a primeira tarefa “adquiriu” o lock.

As próximas tarefas farão a mesma coisa. Mas quando eles invocarem a função atomic_flag_test_and_set, ela novamente irá definir o mutex para verdadeiro, mas isso é irrelevante. O que importa mesmo é que a função retorna, atomicamente, o valor definido pela primeira tarefa, que é verdadeiro no caso. Com isso, a condição do laço while se torna verdadeira, e essa tarefa ficará rodando no laço (por isso spinlock. Sacou? Sacou?) até que a primeira tarefa chame a função release_mutex, que atomicamente irá definir o lock como falso. Agora, dentro da condição do laço while, a segunda tarefa novamente chamará a função atomic_flag_test_and_set, que setará o mutex como verdadeiro (é o que ela está tentando fazer desde o início!!) mas o valor retornado será falso, já que a primeira tarefa já liberou o lock.

Note, contudo, que esse tipo de spinlock não garante ordem. Se mais de uma tarefa estiver esperando pelo lock, a primeira escalonada logo após a liberação será a próxima a adquirir o lock, independente da ordem que as tarefas chegaram a esse ponto (estou considerando um kernel preemptivo em que as tarefas podem ser interrompidas em qualquer momento). Em geral, para tarefas que não possuem ordem de execução, essa solução é satisfatória. Se a ordem é importante, essa solução não pode ser usada dessa forma.

Outra consideração é que se a tarefa que estiver bloqueando as outras levar muito tempo para liberar o lock, há desperdício de CPU das tarefas bloqueadas rodando no loop em vão.

Para encerrar esse tópico, na arquitetura x86 não temos bem uma instrução Test and Set, mas temos uma instrução que faz algo parecido atomicamente: a instrução xchg. Essa instrução troca dois operandos de forma atômica. Portanto, se um dos operandos for 1 (nosso valor verdadeiro do spinlock), o outro é o valor antigo que deve ser testado. Funciona da mesma forma.

Para um kernel não-preemptivo, contudo, não podemos usar essa solução. Afinal, ninguém vai tirar a tarefa de execução se ela mesmo não o fizer usando usando yield. Vamos então para a próxima solução, que é a usada no nosso kernel.

Filas de tarefas bloqueadas

O melhor exemplo é a prática, então vamos aprender fazendo. O primeiro passo é adicionar um estado dentre os possíveis por nosso PCB: BLOCKED. Na classe PCB, adicionamos o método block abaixo:

...
enum TASK_STATUS { READY, RUNNING, EXITED, BLOCKED };

class PCB {
...
  void block() { status = BLOCKED; };
...

Espero que o código acima seja autoexplicativo. Agora, adicionamos a nova classe no arquivo kernel.h:

...
#include <atomic>
...

class Lock {
  std::atomic_bool mutex{false};
  Datastructure::QueueNode<PCB> *blocked{nullptr};

public:
  void lock_acquire();
  void lock_release();
  void block(Datastructure::QueueNode<PCB> *task) {
    ...
    if (blocked == nullptr) {
      blocked = task;
    } else {
      blocked->insert(task);
    }
  }
  Datastructure::QueueNode<PCB> *unblock() {
    Datastructure::QueueNode<PCB> *tmp = blocked;
    ...
    this->blocked = blocked->remove(tmp);
    return tmp;
  }
};

Aqui, demos aquela roubada básica e usamos o tipo atomic_bool do namespace std, padrão do compilador. Como a própria página do OSDev informa:

Então maravilha, estamos em um ambiente freestanding (sem stdlib), e ainda assim nosso código vai funcionar. Quando chegar o ponto exato, eu mostro o código assembly gerado pelo compilador, matando assim a cobra e mostrando a cobra, como diria alguns. Não achei que mostrar o pau fosse apropriado, se contenha.

Note também que temos uma fila de PCB chamada blocked. Espero que o nome seja explicativo o suficiente, é isso mesmo que você está pensando. Quando uma tarefa é bloqueada por não obter o lock, ele vem para essa fila aqui.

Mas que blasfêmia! Quer dizer que o escalonador não tem controle sobre os processos bloqueados pelos locks? Quem tem gerência sobre isso. Então, pequeno gafanhoto, é isso ai mesmo. Quem tem controle sobre os processos bloqueados por não se obter o lock é a própria classe Lock.

Os métodos block e unblock apenas manipulam a fila de tarefas bloqueadas por esse lock, seja inserindo-a na fila ou devolvendo a primeira tarefa “desbloqueada”. Note já que aqui, a ordem de aquisição de locks é preservada. We’ve halfway there.

Vamos ver os outros dois métodos, que estão no arquivo lock.cpp:

#include "include/kernel.h"
#include "include/util.h"
#include <atomic>

extern Scheduler sched;

void Lock::lock_acquire() {
  if (this->mutex.exchange(true)) {
    sched.block(this);
  }
}
...

Parece simples. A primeira coisa diferente de outros lugares que você verá por ai é que outras soluções chamam um método chamado lock_init (o próprio P2 prevê isso, vá lá checar!). No nosso caso, não precisamos, afinal estamos usando C++, programação orientada a objetos (COF COF) e, bem, o construtor já fez isso pra gente:

std::atomic_bool mutex{false};

Indo para as funções de aquisição e liberação do lock, perceba que ela é muito parecida com a do spinlock. A diferença no lock_acquire é que apenas um if é suficiente. Se o mutex já tiver sido adquirido por outra tarefa, solicitamos ao escalonador que bloqueie a tarefa atual. O this do sched.block(this) não é a tarefa, observe a classe do método em questão. Na verdade solicitamos ao escalonador que bloqueie a tarefa atual e a insira na fila de bloqueados deste Lock(this).

E o que o block do escalonador faz? Vamos olhar:

void Scheduler::block(Lock *lock) {
  current_task->get().block();
  lock->block(current_task);
  // Util::printk("Blocking task %d\n", current_task->get().get_pid() + 1);
  scheduler_entry();
}

Ele altera o estado da tarefa atual e a insere na fila de bloqueados desse lock. Após isso, a tarefa atual não tem mais condições de continuar. Por isso, o escalonador invoca a scheduler_entry, que como vimos anteriormente, invoca a função scheduler, que é quem escolhe a nova tarefa para execução. A tarefa bloqueada, quando liberada, continua a execução de onde parou, ou seja, a linha logo após sched.block(this); da função Lock::lock_acquire. Como não há nada mais ali para ser executado, essa função só retorna e a tarefa continua executando normalmente.

E a função atômica que você me prometeu hein, você está me enrolando! Calma, pequeno padawan, se colocarmos um breakpoint na linha this->mutex.exchange(true):

Há! olha ali na memória 0x1dc8 a instrução xchg, cqd.

E quando a tarefa em questão não precisa mais do lock? Ai ela invoca Lock::lock_release.

...
void Lock::lock_release() {
  if (this->blocked != nullptr) {
    sched.unblock(this);
  } else {
    ...
    this->mutex.store(false);
  }
}

Note que se há tarefas bloqueadas na fila, ele desbloqueia a tarefa mas não libera o lock ainda!!! Quem vai fazer isso é a última tarefa da fila de lock, que faz isso de forma atômica na linha this->mutex.store(false);.

Vamos ver o que ocorre na sched.unblock(this);.

...
void Scheduler::unblock(Lock *lock) {
  Datastructure::QueueNode<PCB> *tmp = lock->unblock();
  tmp->get().ready();
  // Util::printk("Unblocking task %d\n", tmp->get().get_pid() + 1);
  this->resched(tmp);
}

A diferença notável aqui é que primeira tarefa da fila blocked do Lock em questão só muda de fila; ela sai da fila do lock e vai para a fila ready_queue do escalonador. Mas, diferente de lock_acquire, o escalonador não é invocado! A tarefa que liberou o lock possivelmente liberou outra, mas ela continua a execução normalmente, afinal, ela ainda não fez do_yield e tampouco do_exit. É isso.

Juntando a parada toda

O P2 apresenta 4 threads que usam um lock, e eles projetaram de uma forma que só há uma ordem de execução desses comandos. Fiz uma pequena alteração e impressões no original para vermos informações úteis na tela. Nossas threads estão assim:

#include "include/tasks.h"
#include "include/kernel.h"
#include "include/screen.h"
#include "include/util.h"

Lock lock;
int order = 0;

void thread1() {
  Screen::set_pos(0, 0);
  Util::printk("#1 started (%d) and is trying to acquire the lock\n", order++);
  lock.lock_acquire();
  Util::printk("#1 acquired the lock and yielded (%d).\n", order++);
  do_yield();
  Util::printk("#1 woke up (%d).\n", order++);
  lock.lock_release();
  Util::printk("#1 released the lock and exited (%d).\n", order++);
  do_exit();
}

void thread2() {
  int thread2_order = 0;
  Screen::set_pos(5, 0);
  Util::printk("#2 started (%d).\n", order++);
  while (true) {
    Util::printk("                      \n");
    Util::printk("                      \n");
    Screen::set_pos(6, 0);
    Util::printk("#2 yielded (t2 %d).\n", thread2_order++);
    do_yield();
    Util::printk("#2 woke up (t2 %d).\n", thread2_order++);
    Screen::set_pos(6, 0);
  }
}

void thread3() {
  Screen::set_pos(9, 0);
  Util::printk("#3 started and yielded (%d).\n", order++);
  do_yield();
  Util::printk("#3 woke up (%d) and is trying to obtain the lock.\n", order++);
  lock.lock_acquire();
  Util::printk("#3 acquired the lock (%d).\n", order++);
  lock.lock_release();
  Util::printk("#3 released the lock and exited (%d).\n", order++);
  do_exit();
}

void thread4() {
  Screen::set_pos(14, 0);
  Util::printk("#4 started (%d) and is trying to obtain the lock.\n", order++);
  lock.lock_acquire();
  Util::printk("#4 acquired the lock (%d).\n", order++);
  lock.lock_release();
  Util::printk("#4 released the lock and exited (%d).\n", order++);
  do_exit();
}

Um teste de mesa aqui é bem útil para você saber o desenrolar da execução. Não é uma dinâmica tão extensa, e sabendo que as tarefas são inseridas nessa ordem na fila de tarefas prontas, você consegue saber certinho como fica a execução. A tarefa dois atrapalha um pouco pois ela não participa do Lock e fica sendo removida e reinserida na fila de prontos a todo momento. Você pode ignorá-la para este propósito.

De lição de casa, compare a sua execução do teste de mesa com o print abaixo. Os números entre parênteses indicam a ordem dos comandos. Com essa primitiva de sincronização, podemos considerar concluído mais uma etapa do P2, faltando apenas várias VÁRIAS outras, mas quem está reclamando?

Esse código, assim como todos os anteriores, está no meu github.

Anterior

Próximo

A demora do último post para este não foi em vão. Neste post, seguindo o P2, começaremos a mexer com troca de contexto de tarefas. Ainda estamos em nível de threads do kernel, portanto nada de syscall ainda, mas a demora vem justamente da dificuldade em fazer algo que em teoria é simples mas que na prática é diferente da teoria.

Já ouviu falar do ovo de Colombo? Existe uma história que Colombo (aquele mesmo) apostava se alguém conseguia colocar um ovo em pé. Na negativa de todos, para os incautos que se atreviam apostar contra, estes se deparavam com o Colombo quebrando um pedaço da base do ovo, permitindo que ele assim ficasse em pé. Nisso, obviamente todos falavam “Ah, mas se fosse pra fazer assim, eu fazia!”. Pois é, e não fez por que, cara pálida?

Enfim, aqui acontece a mesma coisa. Depois que você ver a solução, você vai ficar com cara de trouxa, com todo respeito aos trouxas, amo muito todos eles. E você pode até pensar “Hum, eu faria fácil isso (ou talvez até melhor)”. Longe de duvidar de você, mas há muitas formas de resolver isso, e se você tentar procurar alguma solução na internet, pouco provável que tenha alguma que seja aderente à narrativa proposta pelo P2. Soluções da internet em geral trabalham com TSS e troca de contexto em nível de hardware, que ainda não estamos usando. Sem conhecer a solução por completo, soluções parciais talvez não sejam tão fáceis de se adaptar para nosso contexto.

Duvida? Tente partir do P2 e do nosso último código e tente fazer uma troca de contexto sozinho. Eu fiz esse trabalho em 2020, com várias partes do código já feita pelos professores, nós precisaríamos completar o código pré-existente. Ainda assim, sem consultar esse código original, demorou um tempo para eu fazer funcionar.

E se você já teve (e você deve ter tido) contato com o básico de sistemas operacionais, já deve ter ouvido falar de troca de contexto: quando uma tarefa é interrompida, devemos salvar o “estado” dessa tarefa para retomar do ponto interrompido posteriormente. N arquitetura x86, por estamos estamos nos referindo aos registradores (incluindo o importantíssimo registrador EFLAGS). O problema é que, tal qual o Inception, precisamos executar instruções no processador para salvar tais registradores. Percebe onde quero chegar? É quase como trocar o motor de um avião com ele voando.

Bem, quase isso. Obviamente se este post está sendo escrito, significa que há como fazer isso. Tal qual Jack, vamos por partes.

Antes de adentrarmos nos meandros, o P2 diz isso na seção de Hints:

Então, vamos fazer nossa fila. A fila será útil para várias coisas (várias mesmo), mas para nosso momento, teremos uma fila de tarefas “prontas” e toda vez que precisarmos escolher a próxima tarefa que será executada pelo processador, recorreremos a essa fila.

Obs: falamos bastante de pilha até esse momento, e agora fila. Se não ficou claro, estruturas de dados são muito importantes em Ciência da Computação e agregados, e no desenvolvimento de Sistemas Operacionais isso não é diferente. Não entrarei nos detalhes de tais implementações, sugiro que você chegue neste ponto com tais conceitos dominados.

O arquivo queue.h (final_revisado_v2_AGORA_VAI.txt) está assim:

#ifndef __QUEUE_H
#define __QUEUE_H

namespace Datastructure {
template <class T> class QueueNode {
public:
  T data;
  QueueNode<T> *next, *previous;
  constexpr QueueNode<T>() : next(this), previous(this){};
  constexpr explicit QueueNode<T>(T data)
      : data(data), next(this), previous(this){};

  void insert(QueueNode<T> *);
  QueueNode<T> *remove(QueueNode<T> *);
  void print();
  constexpr T &get() { return data; }
};
} // namespace Datastructure

#endif

Aqui, algumas observações. Não tenho acesso aos operadores new ou delete (tampouco malloc e free), pois não temos stdlib. Tais estruturas já estarão pré-alocadas em algum lugar quando esses ponteiros forem usados.

Outro ponto de atenção é que estou usando templates, notou? Isso porque já sei que usarei tal estrutura em várias situações futuras. E para o momento, testei com o tipo int e com a estrutura PCB, local onde armazenarei o estado do processo e detalharei melhor posteriormente.

Note que isso é uma lista circular duplamente ligada. Quando o nó é criado, os ponteiros next e previous apontam para o próprio nó (this). Temos as opções de insert (insere no fim da fila) e remove (retira do início), como de costume. O método get retorna a referência para o dado em si. Há também o método auxiliar print, para debug, que percorre a lista e vai imprimindo os elementos.

A implementação dos métodos fica no arquivo queue.cpp, e se você já implementou uma fila duplamente ligada, já deve ter feito algo similar:

#include "include/queue.h"
#include "include/kernel.h"
#include "include/util.h"

using namespace Datastructure;

template <class T> void QueueNode<T>::insert(QueueNode<T> *node) {
  this->previous->next = node;
  node->previous = this->previous;

  this->previous = node;
  node->next = this;
...
}

template <class T> QueueNode<T> *QueueNode<T>::remove(QueueNode<T> *node) {
  if (this == node && this->next == this) {
...
    return nullptr;
  }

  QueueNode<T> *tmp = this->next;
  node->previous->next = node->next;
  node->next->previous = node->previous;

...

  return this == node ? tmp : this;
}

template <class T> void QueueNode<T>::print() {
  QueueNode<T> *tmp = this;
  do {
    Util::printk("%d ", tmp->data);
    tmp = tmp->next;
  } while (tmp != this);
  Util::printk("\n");
}

Os … só omitem códigos comentados, que coloquei para fazer debug. Se quiser ver o que tem nesses trechos, vá até o meu github.

E aqui começou os meus problemas. O fato de usar templates e C++ sem ter domínio me fez encarar problemas dos mais variados quando instanciando os tipos QueueNode<int> e QueueNode<PCB>, com o linker reclamando mais que filhote de passarinho com fome.

Graças ao meu bom e velho amigo Dr. Renan Marks, professor da UFMS (visite o site dele: https://renanmarks.net/), o mesmo me enviou uma entrada no StackOverflow que resolveu o meu problema: eu deveria instruir o compilador e mostrar as implementações dos templates para cada tipo específico. Por este motivo sórdido, temos dois arquivos de implementações, queue-impl-int.cpp e queue-impl-pcb.cpp, que no fim das contas são praticamente iguais.

#include "queue.cpp"

template void Datastructure::QueueNode<int>::print();

template void
Datastructure::QueueNode<int>::insert(Datastructure::QueueNode<int> *);

template Datastructure::QueueNode<int> *
Datastructure::QueueNode<int>::remove(Datastructure::QueueNode<int> *);

#include "queue.cpp"

template void Datastructure::QueueNode<PCB>::print();

template void
Datastructure::QueueNode<PCB>::insert(Datastructure::QueueNode<PCB> *);

template Datastructure::QueueNode<PCB> *
Datastructure::QueueNode<PCB>::remove(Datastructure::QueueNode<PCB> *);

Nesse caso, tais arquivos “incluem” o arquivo .cpp. Estranho né? Também achei. Agora, em vez de adicionarmos o arquivo objeto queue.o, adicionamos os arquivos objetos das implementações diretamente, queue-impl-int.o e queue-impl-pcb.o.

Com a fila, templates e C++ superados, vamos para a próxima etapa. Estamos trabalhando com um kernel não preemptivo. Isso significa que as tarefas precisam explicitamente informar que concedem o processador, possivelmente para colaborar com outras tarefas. Elas também podem encerrar a execução. Embora isso seja impensável em um sistema operacional moderno, onde cada tarefa, tal qual o Quico, acha que o processador é só seu e tem toda a memória a sua disposição, aqui vamos em uma abordagem mais simples. Calma que no futuro isso mudará. Por enquanto, assuma as premissas que estou colocando aqui.

Esses slides do P2 mostram bem como é o comportamento das aplicações dessa forma:

Pelas imagens acima, perceba que as tarefas precisam conceder o processador (invocar a função yield). Quando elas encerram, elas chamam a função exit. Para as tarefas de kernel, chamamos as tarefas do_yield e do_exit.

No nosso caso, as tarefas estão no arquivo tasks.cpp, listadas abaixo.

#include "include/tasks.h"
#include "include/kernel.h"
#include "include/screen.h"
#include "include/util.h"

void thread1() {
  Screen::set_pos(0, 0);
  Screen::set_colors(Screen::BLACK, Screen::WHITE);
  Util::printk("Thread 1\n");
  unsigned int i = 0;
  while (i < 20000) {
    Util::printk("                        ");
    Screen::carriage_return();
    Util::printk("%d", i++);
    do_yield();
  }
  Util::printk("\nThread 1 exited!\n");
  do_exit();
}

void thread2() {
  Screen::set_pos(13, 0);
  Screen::set_colors(Screen::WHITE, Screen::BLACK);
  Util::printk("Thread 2\n");
  unsigned int i = 0;
  while (i < 10000) {
    Util::printk("                        ");
    Screen::carriage_return();
    Util::printk("%d", i++);
    do_yield();
  }
  Util::printk("\nThread 2 exited!\n");
  do_exit();
}

As tarefas são simples, apenas para ver o funcionamento da troca de contexto. Cada tarefa entra em um loop, imprimindo um contador. Quando o contador atinge um determinado valor, o loop é encerrado e a tarefa informa que terminou. Os contadores são propositalmente assimétricos, para notarmos quando uma tarefa encerra e a outra não, e quando ambas terminam. Isso é útil para validarmos a fila e a troca de contexto de forma correta (o que deve ocorrer se não há mais tarefas a serem executadas?).

Bom, quando as tarefas forem interrompidas, onde armazenaremos o estado da tarefa? A resposta já foi dita acima, e na estrutura conhecida como PCB, ou Process Control Block. Vamos analisá-lo.

#ifndef __KERNEL_H
#define __KERNEL_H

#include "queue.h"
#include "screen.h"
#include "util.h"
#include <cstdint>

#define NUM_TASKS 2

#define STACK_SIZE 0x1000
#define START_STACKS_ADDRESS 0x41000
enum TASK_STATUS { READY, RUNNING, EXITED };

class PCB {
  uint32_t regs[9]; // EDI, ESI, EBP, original ESP, EBX, EDX, ECX, EAX, EFLAGS
  uint32_t pid;
  TASK_STATUS status;
  bool kernel_thread;
  int display_position = 0;
  char current_color;

public:
  void exit() { status = EXITED; };
  bool is_exited() { return status == EXITED; };
  void ready() { status = READY; };
  void run() { status = RUNNING; };
  void config(void (*)(), uint32_t, uint32_t, bool);
  [[nodiscard]] constexpr int get_display_position() {
    return display_position;
  };
  constexpr void set_display_position(int pos) { this->display_position = pos; }
  constexpr void set_display_color(Screen::Colors foreground,
                                   Screen::Colors background) {
    this->current_color = (foreground & 0x0f) | (background << 4);
  }
  [[nodiscard]] constexpr char get_display_color() {
    return this->current_color;
  };
...
  PCB() {
    this->status = EXITED;
    this->kernel_thread = false;
    this->display_position = 0;
    this->set_display_color(Screen::GRAY, Screen::BLACK);
  };
};

O primeiro ponto importantíssimo é que o primeiro membro da classe NÃO PODE SER ALTERADO. Estou falando no uint32_t regs[9]. Esse vetor guardará o estado dos registradores, e o código que faz isso manipula um ponteiro para PCB e vai tentar fazer isso nesse endereço específico, e com deslocamento esperado do início da estrutura/classe. Os demais membros não tem grandes mistérios. Temos um identificador do processo (pid), o estado da tarefa (para controle do escalonador), se essa tarefa é do kernel ou do usuário. Por fim, cada tarefa armazenará sua própria posição e cores para impressão da printk.

Dos métodos de manipulação do PCB, perceba que vários tratam do estado da tarefa ou de manipulação de posições e cores do display. O que destoa dos demais é justamente o mais importante: config. Vamos ver a cadeia de chamadas para entender o que é feito, pois aqui o negócio começa a complicar. O arquivo principal, kernel.cpp adiciona as tarefas.

  sched.add_task(&thread1, true);
  sched.add_task(&thread2, true);

sched é um objeto do tipo Scheduler que iremos detalhar depois, mas entraremos nessa função add_task, pois isso é importante agora (arquivo scheduler.cpp).

void Scheduler::add_task(void (*entry_point)(), bool kernel_thread) {
  int i = 0;
  while (i < NUM_TASKS) {
    if (this->pcbs[i].get().is_exited()) {
      break;
    }
    i++;
  }

  if (i >= NUM_TASKS) {
    Util::panic("No more PCB available\n");
  }

  this->pcbs[i].get().config(entry_point, this->current_stack_address,
                             this->current_pid++, kernel_thread);
  this->current_stack_address += STACK_SIZE;

  if (this->ready_queue == nullptr) {
    this->ready_queue = &this->pcbs[i];
  } else {
    this->ready_queue->insert(&this->pcbs[i]);
  }
}

O objeto sched possui um array de PCB. Para adicionar uma nova tarefa, precisamos percorrer o vetor e verificar que entrada não está sendo usada (ou seja, a tarefa já terminou, e seu estado é EXITED). Note, isso NÃO é a fila de tarefas prontas, são coisas diferentes! Esse vetor é estático, e se as tarefas encerram de forma aleatória, precisamos encontrar as entradas desocupadas.

Se o vetor for todo percorrido e uma entrada adequada for encontrada, o kernel entra em pânico e congela. Caso contrário, adicionaremos essa tarefa nessa entrada vaga do vetor de PCB. Então:

  this->pcbs[i].get().config(entry_point, this->current_stack_address,
                             this->current_pid++, kernel_thread);

O trecho acima solicita a configuração da nova tarefa, no entry_point determinado (nos exemplos, foi &thread1 e &thread2). O escalonador mantém um controle das pilhas usadas, e informa isso nessa chamada. Os slides mostram onde devemos colocá-las (a partir do endereço 0x40000, cada pilha com tamanho de 4KB ou 0x1000 bytes).

O escalonador mantém ainda um controle do contador de pid para novas tarefas. Quem chamou o método add_task deve informar se essa tarefa é uma tarefa de kernel ou do usuário (kernel_thread). No nosso exemplo, tanto a thread1 quanto a thread2 são threads de kernel.

E o que esse método config faz? Vamos analisá-lo.

void PCB::config(void (*entry_point)(), uint32_t stack, uint32_t pid,
                 bool kernel_thread) {
  this->pid = pid;
  this->regs[3] = stack - 8;
  this->regs[2] = *(uint32_t *)(stack - 8) = stack;
  *(uint32_t *)(stack - 4) = (uint32_t)entry_point;
  this->kernel_thread = kernel_thread;
  this->status = READY;
}

Acredito não haver mistério para os campos pid, kernel_thread e status, certo? Mas o que está acontecendo nas linhas intermediárias? Aqui começa a beleza da coisa. Vamos trabalhar com exemplos? suponha que o entry_point seja 0x1720 e a pilha seja 0x40000. O quarto registrador (regs[3]) recebe o valor 0x3FFF8 (stack - 8). O terceiro registrador (regs[2]) e o endereço apontado por 0x3FFF8 recebem o valor da pilha (0x40000). O endereço apontado pelo endereço 0x3FFFC recebe o entry point, ou seja, 0x1720. Mas afinal, pra quê isso? Bom, eu ainda não falei, mas o regs[3] é o esp e o regs[2] é o ebp. Isso porque a função que usaremos para empilhar os registradores é a pushad, que empilha os registradores em uma ordem específica1. Quando esses dados forem carregados do estado salvo (isso que estamos preenchendo agora) para os registradores, a ideia é que eles e a memória estejam conforme a imagem abaixo.

O truque aqui é que o escalonador, quando selecionar essa tarefa para execução (lembre-se que é a primeira vez dela) recarregará o estado, mas ele continuará a execução como se nada tivesse acontecido até terminar o escopo de sua função. Ao final, ele restaurará o registro de ativação como já bem sabemos: pop ebp, ret. Nós então, malandramente, posicionamos o ponteiro do topo da pilha para o endereço onde essas ações irão acontecer. Quando pop ebp for executado, esp ficará com o valor 0x3FFC e ebp receberá o valor do a instrução pop, que pela imagem no nosso exemplo, é 0x40000. Depois, a instrução ret é executada e ela faz um pop mas para o registrador eip! Nesse ponto, temos os registradores ebp e esp apontando para o mesmo lugar (0x40000) e eip possui agora o entry point da tarefa. A tarefa agora executará normalmente: push ebp/mov ebp, esp/etc. Pronto! Para a primeira tarefa, já temos o fluxo de execução. E se você foi atento (e eu espero que tenha sido), notou que não armazenamos o endereço do entry point no PCB em momento nenhum! Nós só utilizamos os mecanismos da arquitetura x86 contra ela mesma. Esse tipo de estratégia garantia a consistência da pilha entre as chamadas.

Mas e para as tarefas em andamento? Como salvamos a tarefa em execução e recuperamos uma que esteja pronta? Bom, para isso criei a classe Scheduler abaixo no arquivo kernel.h.

class Scheduler {
  Datastructure::QueueNode<PCB> pcbs[NUM_TASKS];
  Datastructure::QueueNode<PCB> *ready_queue;
  uint32_t current_pid{0};
  uint32_t scheduler_count{0};
  uint32_t current_stack_address{START_STACKS_ADDRESS};

public:
  void resched(Datastructure::QueueNode<PCB> *);
  void inc_count() { this->scheduler_count++; };
  Datastructure::QueueNode<PCB> *get_ready_task();
  void add_task(void (*)(), bool);
};

O escalonador possui aquele vetor de PCB dito anteriormente, bem como a fila de tarefas prontas. Ele mantém aquelas informações de PID atual, contagem de escalonamentos e o endereço da pilha válido para a próxima nova tarefa que for criada.

Como métodos, já tratamos do add_task. inc_count acredito que também dispensa comentários. Vamos olhar os outros dois que faltam, começando com get_ready_task.

Datastructure::QueueNode<PCB> *Scheduler::get_ready_task() {
  if (this->ready_queue == nullptr) {
    Util::printk("!!!No more tasks to run!!!\n");
    while (true) {
      /*NO TASKS TO RUN - BUSY WAIT*/
    }
  } else {
    Datastructure::QueueNode<PCB> *tmp = ready_queue;
    this->ready_queue = ready_queue->remove(tmp);
    ...
    return tmp;
  }
}

Essa função apenas remove primeiro elemento da fila. O que ela faz de diferente é que se não houver mais tarefas aptas para execução, ele fica em um loop infinito, afinal, não há o que executar.

O método resched é apresentado abaixo.

void Scheduler::resched(Datastructure::QueueNode<PCB> *task) {
  if (this->ready_queue != nullptr) {
    this->ready_queue->insert(task);
  } else {
    this->ready_queue = task;
    ...
  }
}

Aqui, a mesma coisa. Se a fila estiver vazia, a tarefa que deve ser reescalonada vira a primeira. Caso contrário, ela é inserida no fim da fila.

Mas em que momento o escalonador é invocado? Pois é, ainda não mostramos isso. Nossa premissa de kernel não preemptivo implica que ou a tarefa concede a CPU ou ela termina sua execução. Nos dois casos, o escalonador é invocado e é feito nas funções do_yield e do_exit, no arquivo scheduler.cpp.

void do_yield() {
  current_task->get().ready();
  sched.resched(current_task);
  scheduler_entry();
}
void do_exit() {
  current_task->get().exit();
  scheduler_entry();
}

São as funções mais bestas do universo. A primeira, do_yield, coloca a tarefa em execução do status RUNNING para READY. Ele então reescalona e tarefa e chama a função scheduler_entry. Suspeito.

Já para a função do_exit, ele coloca o status da tarefa em EXITED (para assim aproveitar seu PCB para novas tarefas) e novamente chama a função scheduler_entry. Muito suspeito.

Afinal, o que essa scheduler_entry faz? Muita calma, pois esse é o coração da troca de contexto, e qualquer vacilo faz com que o kernel pare de funcionar (acredite em mim).

Esse é o caminho crítico, é nesse trecho que há o salvamento e restauração da do estado das tarefas. O problema é salvar o estado, usando instruções do processador que não alterem o estado sendo salvo.

Não entendeu? A maioria das instruções alteram o estado do processador, e por estado eu digo o registrador EFLAGS. Fez uma operação matemática e deu overflow? O Campo OF (Overflow Flag) é alterado. Fez uma operação matemática e deu zero? O campo ZF (Zero Flag) é alterado. Fez operações que teve o vai-um no último bit? O campo CF (Carrier Flag) é alterado. Fez operações de movimentação de bytes? O campo DF (Direction Flag) pode ser alterado. Um simples cálculo de deslocamento de bytes dentro de uma estrutura pode mudar o estado do processador, dependendo de como é feito.

Por sorte, algumas instruções não mudam o estado: push/pop, mov, lea. Essas podemos usar. Então, meu algoritmo para salvar o estado é o seguinte:

1. Começamos criando o registro de ativação da função scheduler_entry, como de costume. Portanto, push ebp/mov ebp, esp.

2. Preciso salvar o endereço de esp em algum ponto. Esse é o endereço da pilha da tarefa em execução, e você já vai entender o motivo. Por sorte, o registor de ativação já fez isso pra gente, esse valor está em ebp agora.

3. Enquanto conseguimos salvar alguns registradores individualmente com operações push e mov, isso não é possível para o EFLAGS. A ÚNICA forma de se fazer isso é usando a instrução pushfd. E isso é feito na pilha. Já que essa é a saída, temos uma instrução que salva todos os registradores de propósito geral de uma vez: a instrução pushad.

4. Mas executar isso com a pilha desse jeito não me adianta, eu preciso salvar em um lugar específico para restauração posterior: no PCB da tarefa ativa. Por sorte, essa estrutura está na variável current_task.

5. Eu preciso enganar estão o processador, apontar esp para essa estrutura e fazer as operações de push. Na verdade, lembre-se que a pilha cresce para baixo. Eu preciso calcular quantos bytes essas instruções pushfd e pushad salvam, de modo que ao final desses dois pushs, o endereço apontado por esp seja igual ao do início da estrutura PCB ativa. No nosso caso, são salvos 9 registradores de 32 bits (EDI, ESI, EBP, original ESP, EBX, EDX, ECX, EAX, EFLAGS). Portanto, 9 vezes 4. Nesse ponto, esses 9 registradores estão salvos em uma área da memória, especificamente no PCB da tarefa em execução.

6. Note no passo anterior que ele está salvado o esp original da chamada da instrução pushad. Contudo, quando executo essa instrução, esp está apontando para o PCB, e não para uma pilha válida. Mas por sorte temos esse valor, ele está em ebp como dito anteriormente. Salvamos esse valor também no PCB.

7. A tarefa está completamente salva. Restaure o endereço válido da pilha, para que as próximas instruções possam utilizar de forma correta. Novamente, esse endereço está em ebp.

8. Chame a função scheduler para escolher a próxima tarefa apta.

A função de salvar o estado está completa, e mostrarei ela logo mais. Para melhor entendimento, vamos ver o que essa função scheduler faz.

extern "C" void scheduler() {
  sched.inc_count();
  current_task = sched.get_ready_task();
  current_task->get().run();
}

Então essa função só incrementa o contador do escalonador, pega uma nova tarefa apta e a coloca para “rodar” (na real ele só altera o status para RUNNING). O segredo aqui é que, ao final dessa função, a variável current_task foi alterada para uma nova tarefa!

E se uma nova tarefa foi escolhida, é hora de restaurarmos o estado dela. Como fazemos isso? Siga o algoritmo abaixo:

1. Quando a função scheduler encerra, esp ainda está apontando para a pilha da tarefa anterior. Fazemos o mesmo truque e apontamos esp para o PCB da tarefa ativa (current_task).

2. Faremos a operação inversa, usando instruções popad e popfd. Dessa vez, apontamos para o início da estrutura mesmo. As instruções pop incrementam o valor de esp e portanto esse endereço parte do início do PCB e vai até onde salvamos todos os registradores (note a importância desse primeiro membro da estrutura PCB - regs[9]).

3. EM TEORIA, os registradores já possuem todos os valores restaurados. Em teoria, pois se você ver o manual da instrução popad2, verá que esp não vem do PCB, afinal, a própria instrução popad manipula esse registrador. Não tem problema. Depois do fim da execução de popad e popfd, temos certeza que esp está apontando para &PCB + sizeof(regs[9]). Se fizermos [esp - (6*4)], pegaremos o valor salvo de regs[3], que é o nosso esp salvo.

E é isso. Ao final desse processo, temos o esp apontando para o registro de ativação da tarefa atual, que empilhou o endereço de retorno (com a instrução call) e o ebp antigo (com a instrução push ebp, no começo da função para estabelecimento do registro de ativação). A função termina fazendo pop ebp e ret, retornando para a tarefa que foi escolhida pelo escalonador.

Eu apresentei algoritmos até agora pois esses passos são feitos em assembly. Segue o conteúdo do arquivo entry.asm.

global scheduler_entry
extern current_task, scheduler

scheduler_entry:
    push ebp
    mov ebp, esp
    mov esp, [current_task]
    lea esp, [esp + (9*4)]
    pushfd
    pushad
    mov [esp + (3*4)], ebp
    mov esp, ebp
    call scheduler
    mov esp, [current_task]
    popad
    popfd
    mov esp, [esp - (6*4)]
    pop ebp
    ret

Depois que está pronto, até parece simples. Mas o segredo é o valor de current_task quando a função inicia não é o mesmo de quando ela termina. Tanto essa variável como a função scheduler estão definidos no arquivo scheduler.cpp e por isso são marcados como externos.

Para finalizar, temos apenas que ter cuidado com a primeira vez que a função scheduler_entry é invocada. Afinal, quando isso acontece, não há nenhuma tarefa ativa escolhida pelo escalonador, quem está chamando essa função é a função principal _start do kernel.

Para resolver isso, criei um PCB espantalho, e já inicio o current_task apontando para ele.

Datastructure::QueueNode<PCB> dummyPCB;
Datastructure::QueueNode<PCB> *current_task = &dummyPCB;

Assim, quando a scheduler_entry é invocada a primeira vez, a função irá salvar os valores dos registradores e pilha em dummyPCB. Como não há intenção de retornar a execução de _start depois que o escalonador for invocado, a função scheduler_entry salvará o estado em dummyPCB, mas depois que a função scheduler for invocada, uma tarefa válida já terá sido escolhida.

Você poderia se perguntar: não seria mais fácil usar uma flag e testar se a primeira vez? O problema disso é justamente que as instruções de desvio dependem de alteração das EFLAGS (é assim que elas funcionam inclusive). Portanto, mas simples e direto é mandar salvar os registradores em um área morta mas a lógica global não é alterada.

No fim das contas então, a função _start adiciona as tarefas e chama a função do_exit. Essa função altera o estado da tarefa corrente para EXITED (e a tarefa corrente está apontando para dummyPCB). do_exit, por sua vez, invoca a scheduler_entry, como já falamos anteriormente. A função _start ficou assim então:

extern Scheduler sched;

extern "C" void _start() {
  _init();
  GDT::install_gdt();

  Screen::clear_screen();
  // test_queue();

  sched.add_task(&thread1, true);
  sched.add_task(&thread2, true);

  do_exit();

  while (true) {
    /* BUSY LOOP*/
  }

  /*If code has landed here, something very wrong happened...*/
  _fini();
}

Achou fácil? Pois eu que fiz não achei. São muitos detalhes sórdidos para que isso funcione a contento. O resultado pode ser visto no vídeo abaixo.

A lista de objetos no Makefile aumentou, agora temos:

OBJS:=screen.o gdt.o util.o tasks.o scheduler.o entry.o queue-impl-int.o queue-impl-pcb.o

Mas perto do que acabamos de mostrar, isso ai é fichinha e foi só para conhecimento. O código completo pode ser visto no meu github.

Anterior

Próximo

No post anterior nós conseguimos resolver o problema dos construtores. Agora me sinto mais confiante para usar outros recursos da linguagem C++, como namespaces etc. Aproveitei e dei uma organizada no código, e conto com o compilador para me impedir coisas que não posso (como RTTI, exceções, etc).

O meu código está bem longe do que é cobrado no P2, mas precisamos de um arcabouço de ferramentas para nos ajudar quando precisarmos colocar a mão na massa de verdade. E na parte de Hints é dito “Adding print_int and print_str to your program can help you debug.”.

Eu não poderia concordar mais. Consigo me virar bem com o GDB, mas nem sempre o código que vejo em C bate com o que eu faria em assembly, especialmente por causa das otimizações (parâmetro -O2 no g++ e ld). Uma função que mostra endereços e números na tela ajudaria bastante.

E se vamos fazer print_int e print_str, por que não fazer logo um clone (humilde, acalme-se) da função printf? E como estamos em kernel mode, da então nomeada printk!

E se estou escrevendo um post para isso, significa que há coisas a serem ditas sobre. Se você fez faculdade de computação, é possível que você já saiba do que eu estou falando e isso não seja novidade para você. Caso contrário, é uma ótima oportunidade para você entender de verdade como funcionam as funções com parâmetros variáveis.

Não é coisa de outro mundo, mas se a linguagem não permitir, você não consegue fazer esse tipo de implementação. No Java por exemplo, o printf só apareceu na versão 1.5 e foi necessário fazer alterações na arquitetura da JVM para acomodar essa mudança1.

Mas então, qual é a treta? Lembrando que tudo o que eu vou falar aqui vale para a arquitetura x86 de 32 bits.

A assinatura da função printk é a seguinte:

void printk(const char *, ...);

E um uso dessa função seria, por exemplo:

printk("\tTesting line feed! %c %x %o\n%s", 'X', 0xb8000, 0700, test);

Se você nunca viu uma printf antes, calma que vou explicar tudo. Observe que o primeiro parâmetro é obrigatoriamente uma string (no caso, um ponteiro de caracteres: "\tTesting line feed! %c %x %o\n%s"). Mas os outros parâmetros podem ser qualquer coisa: string, inteiro, caracteres. Como você programa uma função sem saber de antemão quais são os parâmetros, ou, pior ainda, como acessá-los?

Bom, primeiro veja que o primeiro parâmetro dita o número de parâmetros que virão a seguir, e mais do que isso, seu tipo. Os parâmetros no primeiro parâmetro são identificados pelo caractere % seguido do tipo. Então, em nosso exemplo, temos os parâmetros:

• %c é o caractere 'X'

• %x é o número hexadecimal 0xb8000

• %o é o número octal 0700

• %s é a cadeia de caracteres armazenada na variável test. No meu código, eu defini essa variável um pouco antes dessa forma: char test[] = {'t', 'e', 's', 't', '\0'};

Além desses parâmetros, ainda seria possível usar mais dois: %d para números decimais e %% para o imprimir caractere ‘%’. Isso tudo é arbitrário, eu que defini que seria dessa forma, mas tentei manter um padrão parecido com a função printf original do C. Na função original do C, por exemplo, há vários outros tipos, como o tipo %f para números de ponto flutuante.

Ok, e e o que fazemos com isso? Bom, o algoritmo básico é basicamente percorrer a string do primeiro parâmetro imprimindo os caracteres. Caso você encontre um caractere especial (digamos, \n, \t ou %) ai é necessário fazer coisas adicionais. Vamos para os mais fáceis primeiro.

Para o \t, defini que a tabulação equivale a quatro espaços em branco na tela. Então, se um \t for encontrado, nada mais simples do que imprimir ‘ ‘ quatro vezes:

...
    case '\t':
      for (int i = 0; i < 4; i++) {
        Screen::print_char(' ');
      }
      break;
...

Para o \n, estou usando o padrão do Linux. Significa que ele faz um Line Feed e um Carrier Return ao mesmo tempo. Dada uma posição do cursor na tela, se você somar a essa posição o número de colunas do display, você obrigatoriamente parará na próxima linha. Depois, basta recuar para a posição zero dessa linha (recua o número de caracteres igual a posição atual menos o resto da divisão da posição atual com o número de colunas. Fica assim:

util.cpp
...
    case '\n':
      Screen::line_feed();
      break;
...

screen.cpp
void Screen::line_feed() {
  current_position += NUM_COLUMNS;
  current_position -= current_position % NUM_COLUMNS;
  current_position = current_position % (NUM_ROWS * NUM_COLUMNS);
}

A última linha é necessária quando o cursor estoura o tamanho máximo do display, e no caso ele é recolocado na tela.

Fácil? Até agora não foi necessário acessar parâmetro nenhum adicional, além do primeiro. Vamos dificultar um pouco. Se encontrarmos um ‘%’, precisamos avançar e ver o próximo caractere, para identificar o tipo do parâmetro. E para desvendar o mistério sem mostrar o código, precisamos relembrar de algumas coisas no que diz respeito a ABI dos compiladores C/C++ para a arquitetura x86 de 32 bits:

1. A pilha cresce para baixo

2. Os parâmetros são empilhados na ordem inversa da declaração

3. Cada elemento na pilha ocupa 32 bits (4 bytes)

Com base nisso, vamos ver como está a pilha quando a função é invocada com os parâmetros do nosso exemplo na imagem abaixo.

Então, quando chamamos printk("\tTesting line feed! %c %x %o\n%s", 'X', 0xb8000, 0700, test);, o compilador:

1. Empilha o endereço da variável test

2. Empilha o valor 0700 (octal)

3. Empilha o valor 0xb8000 (hexadecimal)

4. Empilha o caractere ‘X’. Observe que o caractere ‘X’ só ocupa 1 byte. Ainda assim, 4 bytes são usados e o restante dos 24 bits mais significativos são zerados

5. Empilha o endereço da string "\tTesting line feed! %c %x %o\n%s"

6. Chama a função printk. A instrução call automaticamente empilha o endereço de retorno

7. Já na função printk, a primeira coisa que é feita é ajustar a pilha, ou seja criar o registro de ativação dessa nova função. A função empilha o endereço base da função que chamou (caller ebp → instrução push ebp) e altera seu valor para o mesmo do topo da pilha (callee esp → mov ebp, esp). Esse é o novo endereço base da pilha da função printk (ebp) e permanece inalterado até a função retornar. Já o ponteiro do topo da pilha (esp) pode ser alterado (e provavelmente vai, se houver variáveis locais ou chamadas de outras funções).

O segredo todo está em apontar para o endereço da única variável que temos certeza que existe, a primeira. Como o ebp agora é a nossa âncora da pilha, observe na imagem abaixo os endereços indexados pelo registrador ebp.

O segredo é portanto definir uma âncora no único parâmetro que temos certeza, o fmt address [ebp+8]. Ao percorrer a string fmt, toda vez que encontrarmos um novo % indicando ser um parâmetro, basta pegar essa âncora e incrementar 4 para ir voltando na pilha. Assim, partindo do fmt address [ebp+8], para chegar em ‘X’, incrementamos 4 e chegamos em [ebp+12]. Para chegar em 0xb8000, incrementamos 4 e chegamos em [ebp+16] e assim por diante.

O problema todo é que não conseguimos manipular diretamente a pilha em C, pelo menos não da forma como programamos. Inclusive, esse era o problema de não ter printf no Java antes da versão 1.5.

E como a gente resolve isso? Uma alternativa é trabalhar com o endereço da variável fmt. Note, não é o endereço para onde fmt aponta, mas sim o endereço do fmt em si. Isso porque o endereço dele, como vimos, é a pilha. Você pode trabalhar com aritmética de ponteiros para isso, vai funcionar. O cuidado que se precisa ter é que há alguns tipos de dados que podem ocupar mais que 4 bytes (um long long talvez?).

Para facilitar, há algumas macros que nos auxiliam nisso, chamadas variadic functions2, que são macros declaradas no arquivo stdarg.h ou cstdarg para C++, que é o nosso caso. Faremos tal qual eu disse antes. Primeiro, declaramos a variável âncora.

std::va_list args;

Essas macros são independentes de arquitetura e por isso o *USO* deve ser tal qual eu vou mostrar aqui, mesmo que no fim das contas, algumas macros não façam nada na nossa arquitetura. Isso porque existem arquiteturas que guardam alguns parâmetros em registradores e outros na pilha, e há arquiteturas que possuem tantos registradores que é bem possível que a pilha nem seja usada. Dessa forma. se usarmos como manda o manual, não teremos problema. De qualquer forma, explicarei o que acontece na nossa arquitetura x86 32bit.

Voltando então, por trás dos panos, na nossa arquitetura, essa declaração expande para um char*3. Por enquanto, ela não armazena endereço nenhum. Precisamos agora obter nossa âncora:

va_start(args, fmt);

Essa macro, na nossa arquitetura, armazena o endereço de fmt na variável args, ou seja, temos em args o valor ebp+8.

Quando precisarmos do próximo elemento, basta chamar a macro va_arg, passando a âncora e o tipo do dado. Por exemplo, se o próximo parâmetro é um int, então:

n = va_arg(args, int);

Simples assim. A variável n conterá o dado solicitado, e a âncora é atualizada, e ficará pronta para o próximo parâmetro. Digamos que agora queiramos o próximo parâmetro, que é uma string. Assim, basta fazer:

char *s = va_arg(args, char *)

E o processo se repete. Quando tivermos percorrido todos os parâmetros na pilha, precisamos encerrar o processo chamando va_end(args);.

Na arquitetura x86, essa macro pode não fazer nada. Ou pode anular o valor de args propositalmente para que novos acessos a ele sejam inválidos. Isso vai depender do compilador. O fato é que, por questões de compatibilidade com outras arquiteturas e aderência ao padrão proposto, invocamos essa macro também. É inclusive bom para deixar o código legível e ver os limites da utilização dessa variável no código. O início da função fica como a seguir, e o restante é só repetição mas para tipos de dados diferentes.

void Util::printk(const char *fmt, ...) {
  std::va_list args;
...
  va_start(args, fmt);
  for (const char *c = fmt; *c != NULL; ++c) {
    switch (*c) {
    case '%':
      switch (*++c) {
      case 's':
        for (const char *s = va_arg(args, const char *); *s != NULL; ++s) {
          Screen::print_char(*s);
        }
        break;
...

A mágica perdeu o encanto? Excelente, essa é a ideia. Só tem um detalhezinho que ainda não abordamos: Se o parâmetro for um número (decimal, hexadecimal, octal, que seja), como a função imprime esse valor?

Não entendeu a pergunta? Eu te explico: Quando falamos de memória de vídeo nesse artigo AQUI, dissemos que passamos dois bytes para cada caractere: um para o caractere em si, outro para o atributo de cores de frente e fundo. Tudo muito bonito, mas estamos trabalhando com números de 32 bits (4 bytes) na pilha e nos registradores. Como encaixamos isso em um byte para escrever na memória de vídeo?

Mais do que isso, não podemos escrever o “valor” do caractere diretamente. Isso porque a memória de vídeo obedece a tabela ASCII. Se você quiser escrever o caractere zero (0) na tela, na verdade o valor do byte deve ser 48 ou 0x30.

Precisamos de um algoritmo para transformar um número de 32 bits em uma cadeia de caracteres que seja a representação desse número. Se você trabalha com computação, você já deve ter aprendido o algoritmo de mudança de base. Por exemplo, para transformar o número 159 em binário, basta aplicar divisões sucessivas pela base (na base binária, por 2) e recuperar os restos da divisão em ordem contrária. O mesmo serve para a conversão para hexadecimal ou octal. Observe a imagem abaixo.

Observe que para hexadecimal há uma pegadinha, que você já deve saber mas que não custa falar anyway. A base 16 indica que temos dezesseis símbolos que a representam. Contudo, só temos 10 símbolos para números: de 0 a 9. Portanto, para a base 16, quando temos dígitos que seriam de 10 a 15, pegamos emprestado do alfabeto as primeiras letras: 10 vira A, 11 vira B, e vai assim até 15 virar F.

Criamos então a função itoa (int to ascii). Essa função provavelmente está em toda função de biblioteca, de várias linguagens diferentes. Mas como essa função não é definida em ANSI-C e não é parte do C++ (apesar de ser suportada por alguns compiladores), nós criamos nós mesmos a função. Veja o código abaixo.

char *Util::itoa(int number, int radix, char *tmpBuff) {
  int i = 0;
  int j = 0;
  char tmp[100];
  if (number < 0) {
    tmpBuff[i++] = '-';
    number *= -1;
  }
  if (radix == 8 || radix == 16) {
    tmpBuff[i++] = '0';
  }
  if (radix == 16) {
    tmpBuff[i++] = 'x';
  }

  do {
    char c = number % radix;
    if (radix == 16 && c >= 10) {
      c = c + 'A' - 10;
    } else {
      c = c + '0';
    }
    tmp[j++] = c;
    number /= radix;
  } while (number > 0);

  while (--j >= 0) {
    tmpBuff[i++] = tmp[j];
  }
  if (radix == 2) {
    tmpBuff[i++] = 'b';
  }

  tmpBuff[i++] = '\0';
  return tmpBuff;
}

Começamos verificando se o número é negativo. Afinal, é importante o sinal de menos quando isso acontece certo? Se sim, adicionamos esse símbolo em um vetor temporário de caracteres. E depois, invertemos o número para prosseguir com o algoritmo.

Depois, verificamos a base. Por conversão, números na base octal recebem um zero antes, e números hexadecimais, 0x, e números binários possuem um b ao final (por isso seu teste é feito ao final).

Por fim, aplicamos o algoritmo da imagem acima. Pegamos o número inicial e obtemos o resto. Com esse resto, descobrimos o equivalente da tabela ASCII. Para os números normais de 0 a 9, caso eu some a esse número o valor de ‘0’ na tabela (48), vamos resultar com o caractere desejado. Por exemplo, caso eu deseje escrever o caractere 4 na tela, de posse do número 4, ao somar ‘0’ (portanto 48) resulta em 52. Veja que 52 decimal na tabela ASCII é igual ao caractere 4.

Para os caracteres hexadecimais, se o número for 12 por exemplo, não basta aplicar o mesmo raciocínio e somar ‘A’ (65). Isso vai resultar em 77 que na tabela ASCII é igual ao ‘M’. Basta tirar 10, que chegamos em 67 e ao caractere ‘C’, agora sim, correto.

Depois de armazenar o resto, atualizamos o número para o divisor da divisão anterior. E repetimos o processo até o número ser igual a zero.

Acabou? Não, observe a imagem, esse vetor de caracteres temporários está guardando os caracteres de trás pra frente. Somente quando o número chega a zero que temos o primeiro dígito. Então, basta percorrer o vetor de trás para frente e ir copiando os dados para o destino.

Pronto, terminamos. O resultado do código da função kernel.cpp abaixo

extern "C" void _start() {
  _init();
  GDT::install_gdt();

  char test[] = {'t', 'e', 's', 't', '\0'};

  Screen::set_colors(Screen::RED, Screen::YELLOW);
  Screen::clear_screen();
  Util::printk("Hello %s %d!\n", "Rodrigo", -42);
  Util::printk("\tTesting line feed! %c %x %o\n%s\n", 'X', 0xb8000, 0700, test);
  Util::printk("%d in binary is %b\n", 75, 75);

  while (true) {
    /* BUSY LOOP*/
  }

  /*If it reaches here, something very wrong happened...*/
  _fini();
}

resulta em

Essa nem foi tão difícil, até porque tem pouca coisa de Sistemas Operacionais ou kernel. Os próximos posts voltarão para o tópico de interesse. O código até o momento pode ser visto AQUI. Até mais!

Anterior

Próximo

Depois de muito quebrar a cabeça no post anterior, finalmente consegui fazer os construtores globais funcionar no nosso código. Passei dias no readelf e objdump tentando entender o que o compilador fazia (ou não fazia) e o que foi necessário alterar para que isso acontecesse.

Eu alterei o código das classes GDT e GDTPointer para que as construíssemos através de construtores. Também adicionei um destrutor na classe GDTPointer para fins didáticos e de testes, uma vez que tudo estiver funcionando esse destrutor será removido. No momento, ele só chama a função printk para sabermos se o destrutor está sendo invocado. As classes ficaram assim:

class GDT {
public:
  uint16_t limit_bytes_0_1 = 0;
  uint16_t base_address_bytes_2_3 = 0;
  uint8_t base_address_byte_4 = 0;
  uint8_t type_access_byte_5 = 0;
  uint8_t limit_flags_byte_6 = 0;
  uint8_t base_address_byte_7 = 0;

  GDT(uint32_t base_address, uint32_t limit, uint8_t type, uint8_t flags) {
    this->limit_bytes_0_1 = limit & 0xffff;
    this->base_address_bytes_2_3 = base_address & 0xffff;
    this->base_address_byte_4 = (base_address >> 16) & 0xff;
    this->type_access_byte_5 = type;
    this->limit_flags_byte_6 = (limit >> 16) & 0xf;
    this->limit_flags_byte_6 |= flags;
    this->base_address_byte_7 = (base_address >> 24) & 0xff;
    printk((char *)" GDT() ", YELLOW, BLUE);
  }
  __attribute__((constructor));
} __attribute__((__packed__));

class GDTPointer {
public:
  uint16_t size = 0;
  uint32_t gdt_entries_address = 0;
  ~GDTPointer() { printk((char *)" ~GDTPointer() ", RED, YELLOW); }

  GDTPointer(uint16_t size, uint32_t address) {
    this->size = size;
    this->gdt_entries_address = address;
    printk((char *)" GDTPointer() ", RED, YELLOW);
  }
  __attribute__((constructor));
} __attribute__((__packed__));

A declaração das variáveis globais mudou para usar os construtores no arquivo gdt.cpp, e a função install_gdt foi simplificada de tabela. Esse trecho ficou portanto:

GDT gdt_entries[] = {
    // Null descriptor
    GDT(0,0,0,0),
    // Kernel Code Descriptor
    GDT(0x00000000, 0xfffff,
      GDT_ACCESS_CODE_SEG_READ | GDT_TYPE_CODE_SEG_READ |
          GDT_TYPE_CODE_SEG_NOT_CONFIRMING | GDT_TYPE_CODE_SEG |
          GDT_TYPE_DESCRIPTOR_CODE_OR_DATA | GDT_RING_00 | GDT_TYPE_PRESENT,
      GDT_FLAG_USER_DEFINED | GDT_LONG_MODE_DISABLED | GDT_32BIT_FLAG |
          GDT_GRANULARITY_FLAG),
    // Kernel Data Descriptor          
    GDT(0x00000000, 0xfffff,
      GDT_ACCESS_DATA_SEG_WRITE | GDT_TYPE_DATA_SEG_WRITE |
          GDT_TYPE_DATA_SEG_GROW_UPSIDE | GDT_TYPE_DATA_SEG |
          GDT_TYPE_DESCRIPTOR_CODE_OR_DATA | GDT_RING_00 | GDT_TYPE_PRESENT,
      GDT_FLAG_USER_DEFINED | GDT_LONG_MODE_DISABLED | GDT_32BIT_FLAG |
          GDT_GRANULARITY_FLAG)
};
GDTPointer gdtp((uint16_t)(sizeof(GDT) * GDT_ENTRIES),
                (uint32_t)&gdt_entries[0]);

void install_gdt() {
  GDTPointer testing(0, 0);
    
  asm("lgdt %0" : : "m"(gdtp));
  asm("ljmp %0, $continue_load_gdt_register \n\t"
      "continue_load_gdt_register: \n\t" ::"i"(GDT_KCS_SEL * 0x8));
  asm("mov %0, %%eax \n\t"
      "mov %%ax, %%ds \n\t"
      "mov %%ax, %%es \n\t"
      "mov %%ax, %%fs \n\t"
      "mov %%ax, %%gs \n\t"
      "mov %%ax, %%ss \n\t" ::"i"(GDT_KDS_SEL * 0x8));
}

O trecho GDTPointer testing(0, 0); está ai apenas para testar os construtores e destrutores locais. Uma vez que o teste tenha sido validado, ele será removido no futuro.

Para emitir outro construtor em outro arquivo, para fins de teste também, adicionei a variável global GDT test(0, 0, 0, 0); no início do arquivo screen.cpp. A compilação desses arquivos resulta nessas funções, que são os construtores das variáveis globais:

$ objdump -D build/kernel | grep '_GLOBAL__sub_I'
000012d0 <_GLOBAL__sub_I_test>:
000012f0 <_GLOBAL__sub_I_gdt_entries>:

Perceba que a construção da variável test ficou na função _GLOBAL__sub_I_test (arquivo screen.cpp), e a construção das variáveis gdt_entries e gdtp ficou na função _GLOBAL__sub_I_gdt_entries (arquivo gdt.cpp). O comportamento é esse mesmo, a construção de variáveis globais são agrupadas por unidade de compilação, no nosso caso, cada arquivo .cpp.

Partindo do que foi constatado até o momento, devemos visitar esse artigo AQUI para entender como esses construtores são invocados.

A inicialização de objetos em um compilador GCC/G++ compatível com a ABI do System V utiliza 5 tipos de arquivos especiais: crt0.o, crti.o, crtbegin.o, crtend.o, and crtn.o. Esses arquivos possuem códigos que são executados antes da main() iniciar e depois que ela finaliza. Mas isso ocorre para código de usuários, quando você compila seu programa no gcc para rodar no seu Linux. Como estamos programando um kernel, há uma matemágica necessária que possamos fazer isso. Por exemplo, nosso kernel funcionará como o arquivo crt0.o, e portanto é nossa responsabilidade saber como vamos invocar os construtores.

Vale deixar bem claro que o que vou descrever daqui para frente é dependente de arquitetura, versão do compilador etc. No fim das contas o compilador gerará um vetor de ponteiros para função que armazena os endereços dos construtores (e outro vetor para os destrutores). Nas minhas primeiras tentativas meu compilador estava gerando um vetor oculto chamado __frame_dummy_init_array_entry, mas que deveria ser chamado pela função _init() e por algum motivo isso não acontecia. Algumas frustrações e muito café depois, lendo ESSE artigo cheguei nesse trecho:

In this case things are slightly different. The system ABI mandates the use of special sections called .init_array and .fini_array, rather than the common .init and .fini sections. This means that crtbegin.o and crtend.o, as provided by your cross-compiler, does not insert instructions into the .init and .fini sections. The result is that if you follow the method from Intel/AMD systems, your _init and _fini functions will do nothing. Your cross-compiler may actually come with default crti.o and crtn.o objects, however they also suffer from this ABI decision, and their _init and _fini functions will also do nothing.1

O trecho acima diz que o procedimento que eu estava tentando utilizar não se aplicava à arquitetura ARM. Oras, mas eu não estou usando ARM, estou usando Intel/AMD…

De toda sorte, tentei o procedimento para ARM e fui bem sucedido! Então é esse que vou explicar aqui.

Primeiro, o compilador fornece os arquivos crtbegin.o e crtend.o. Em especial o crtbegin.o, ele possui especialmente um vetor chamado _init_array_start (e o _fini_array_start para os destrutores), que armazenará os endereços dos construtores, e o compilador/linker o irá complementar quando a compilação completa acontecer. Temos portanto um vetor de ponteiros de função (tal qual o __frame_dummy_init_array_entry dito acima).

Nossa missão é portanto criar os arquivos crti.cpp e crtn.cpp, respectivamente o preâmbulo e epílogo dos arquivos crtbegin.o e crtend.o. No arquivo crti.cpp nós dizemos que os símbolos _init_array_start, _init_array_end, _fini_array_start e _fini_array_end estão definidos em outro lugar, mas que vamos referenciá-los. Nós sabemos a fronteira de tais vetores pois o compilador malandramente sabe onde começa e termina as seções .init_array (para os construtores) e .fini_array (para os destrutores) no arquivo ELF, portanto, ao iterar por um vetor de ponteiros para função começando por _init_array_start, quando nosso iterator alcançar _init_array_end, sabemos que o vetor terminou. Se não ficou claro, observe o trecho de interesse da saída do comando objdump -D build/kernel:

Ignore as instruções em assembly do lado direito. Isso é um vetor de ponteiros para função, com três valores, sendo eles: 0x00001150, 0x000012d0 e 0x000012f0 (agrupe de quatro em quatro bytes, e considere a notação Little Endian - byte menos significativo primeiro). E o que esses valores significam? Isso:

$ objdump -D build/kernel | grep '00001150\|000012d0\|000012f0'
00001150 <frame_dummy>:
000012d0 <_GLOBAL__sub_I_test>:
000012f0 <_GLOBAL__sub_I_gdt_entries>:

AHÁ, olhe nossos construtores ai! A primeira entrada diz respeito a coisas que o compilador colocou, isso é o endereço da função frame_dummy, que por sua vez chama a função register_tm_clones… para mais detalhes dessa cadeia de chamadas, veja AQUI. As outras duas entradas dizem respeito aos nossos construtores, ditos anteriormente.

E como a gente acessa esse vetor e invoca essas funções? Ai é que está a mágica do negócio. Pegando como exemplo os construtores (a analogia é a mesma para os destrutores, apenas a seção que é diferente). Primeiro, declaramos o tipo de ponteiro para função func_ptr.

typedef void (*func_ptr)(void);

Declaramos as variáveis _init_array_start e _init_array_end, dizendo que elas são do tipo func_ptr, ou seja, um array de ponteiros para função, e dizemos que o endereço delas não está nesse arquivo .cpp (ou seja, são externas).

extern func_ptr _init_array_start[0], _init_array_end[0];

Vetor de tamanho zero? É isso ai jovem, isso indica para o compilador que é um vetor, mas ele não efetivamente “ocupa” espaço na memória, é apenas um marcador para a posição de memória correspondente. Isso é muito útil e usado em estrutura de dados de tamanho variável, como o encapsulamento de dados nas camadas de rede. Para um explicação simples do motivo disso, veja se esse artigo AQUI consegue esclarecer essa artimanha.

Apontamos o _init_array_start para o início da seção .init_array:

func_ptr _init_array_start[0] __attribute__((used, section(".init_array"),
                                             aligned(sizeof(func_ptr)))) = {};

e o _init_array_end para o fim da seção (é a mesma coisa, mas isso está no arquivo crtn.cpp, o rodapé portanto):

func_ptr _init_array_end[0] __attribute__((used, section(".init_array"),
                                           aligned(sizeof(func_ptr)))) = {};

Agora, no arquivo crti.cpp, chamar tais construtores é tão simples quanto iterar de _init_array_start até _init_array_end, invocando cada um dos ponteiros no processo:

extern "C" void _init(void) {
  for (func_ptr *func = _init_array_start; func != _init_array_end; func++)
    (*func)();
}

Basta então declarar a função _init() no arquivo kernel.cpp e invocá-la antes de tudo:

extern "C" void _init(void);
...

extern "C" void _start() {
  _init();
...
}

É isso! Difícil? Eu achei.

Ainda não acabou. Para tudo isso funcionar, vocês notaram que os arquivos crti.cpp e crtn.cpp trabalham com as seções .init_array e .fini_array no arquivo ELF. Então, ao invés de passar parâmetros de seções diretamente no linker, criamos o arquivo linker.ld com o conteúdo abaixo:

ENTRY(_start)

SECTIONS
{
	. = 0x1000;

	.text BLOCK(4K) : ALIGN(4K)
	{
		*(.text)
	} 	

	/* Read-only data. */
	.rodata BLOCK(4K) : ALIGN(4K)
	{
		*(.rodata)
	}

	/* Read-write data (initialized) */
	.data BLOCK(4K) : ALIGN(4K)
	{
		*(.data)
	}

	/* Read-write data (uninitialized) and stack */
	.bss BLOCK(4K) : ALIGN(4K)
	{
		*(COMMON)
		*(.bss)
	}

	/* The compiler may produce other sections, by default it will put them in
	   a segment with the same name. Simply add stuff here as needed. */  

	.preinit_array     :
	{
		PROVIDE_HIDDEN (__preinit_array_start = .);
		KEEP (*(.preinit_array))
		PROVIDE_HIDDEN (__preinit_array_end = .);
	}
	.init_array     :
	{
		PROVIDE_HIDDEN (__init_array_start = .);
		KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
		KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
		PROVIDE_HIDDEN (__init_array_end = .);
	}
	.fini_array     :
	{
		PROVIDE_HIDDEN (__fini_array_start = .);
		KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*)))
		KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors))
		PROVIDE_HIDDEN (__fini_array_end = .);
	}  
}

Descartamos coisas no linker como -Ttext 0x1000, essa informação está no arquivo linker.ld agora. A invocação fica assim:

...

kernel:  kernel.o $(OBJ_LINK_LIST)
	cd $(OUTPUTDIR) && ld -O2 -g -m elf_i386 -T../linker.ld -z noexecstack -o $@ kernel.o $(OBJ_LINK_LIST)

...

A variável OBJ_LINK_LIST é uma concatenação cuidadosa de nossos arquivos .o, adicionados aos exigidos pelo compilador para geração dos construtores:

OBJS:=screen.o gdt.o

CRTI_OBJ=crti.o
CRTBEGIN_OBJ:=$(shell g++ -m32 $(CFLAGS) -print-file-name=crtbegin.o)
CRTEND_OBJ:=$(shell g++ -m32 $(CFLAGS) -print-file-name=crtend.o)
CRTN_OBJ=crtn.o

OBJ_LINK_LIST:=$(CRTI_OBJ) $(CRTBEGIN_OBJ) $(OBJS) $(CRTEND_OBJ) $(CRTN_OBJ)

E não esqueça de adicionar as flags -fno-exceptions -fno-use-cxa-atexit, caso contrário você terá problemas com o g++:

...

%.o: $(SRCDIR)/%.cpp
	g++ -g -m32 -c $< -o $(OUTPUTDIR)/$@ -O2 -Wall -Wextra -ffreestanding -fno-rtti -nostdlib -fno-exceptions -fno-use-cxa-atexit 

...

É isso. Ao compilar, qual é o resultado? Esse da imagem abaixo:

Note que o construtor da classe GDT foi invocado quatro vezes, três pelas entradas da variável global gdt_entries no arquivo gdt.cpp, e uma pelo teste da variável test no arquivo screen.cpp. O construtor da classe GDTPointer é invocado duas vezes, uma para a variável global gdtp, outra para a variável local testing dentro da função install_gdt. A variável testing inclusive é a única que está dentro de um contexto que é encerrado, ao fim da função install_gdt o destrutor é invocado. Por fim a função printk é invocada dentro da função _start do arquivo kernel.cpp emitindo a mensagem " Hello Protected Mode! ", como já havia antes.

Depois que você vê o código pronto e funcionando, tudo parece simples e óbvio. Mas foi muito difícil chegar a essa solução, em especial por desconhecer esses detalhes do compilador, e construções como __attribute__((used, section(".init_array"), aligned(sizeof(func_ptr)))).

Pouco provável que eu conseguisse fazer isso sozinho, ou pelo menos ia precisar de outras soluções e gambiarras criativas para obter o endereço de _init_array_start. Esse nem seria o problema, mas sim saber o tamanho desse vetor. A artimanha de posicionar códigos de preâmbulo e epílogo na seção .init_array é bem inteligente, eu teria feito de outra forma muito menos sutil, talvez lendo o arquivo ELF ou outra coisa do tipo.

Anterior

Próximo

O post anterior finalizou o P1 criando uma imagem bootável a partir de arquivos ELF. Agora, vamos iniciar o P2. Só que tem uma pegadinha, observe o que é dito na área de Hints:

• The boot loader provided to you for this project does more than the one you wrote last project. Specifically, it enables address line 20 and enters protected mode.

Ok, esse trabalho tem uma parte do código que já vem pronta e não especifica muito o que é feito. Como nós estamos construindo tudo do zero, pois não estamos acessando o código original, é nossa missão fazer essas etapas. E isso não é dito ou explicado no trabalho como é ou deveria ser feito. Vamos então entender o problema e ver como solucionamos.

A20 gate

Muito antigamente, no tempo de guaraná de rolha, os processadores da arquitetura x86 (8086, 8088, 80186, 80188 e variantes) eram da arquitetura 16bit com endereçamento de 20bit. Como você armazena um endereço de 20 bits em um registrador de 16? Você já sabe a resposta, e a mágica é usar registradores de segmentos para compor o endereço: com um registrador de segmentos de 16bit. O maior endereço possível para 20 bits é 2^20 = 1048576 - 1 (já que o endereço começa em zero), ou 0x100000. Isso pode ser representado pela combinação de segmento 0xf800 e offset 0x8000 (0xf800 * 16 + 0x8000).

Até aqui ok, certo? Ai surgiu o processador 80286. Esse processador trouxe o advento do famigerado Modo Protegido, que explicarei mais a frente. Esse processador também trouxe uma expansão do endereçamento, podendo agora usar endereços de 24 bits (e 30bits no modo protegido com MMU, mas não nos avancemos muito. Foquemos nos 24bits).

Contudo, olha a cagada: esses processadores eram vendidos como retrocompatíveis com os sistemas antigos, ou seja, ele deveria emular um 8086 antigo em modo real 16bit, até que você dissesse para ele fazer o contrário, assim, programas antigos escritos para a outra arquitetura continuavam funcionando. Isso na teoria.

Porque, na prática, um programa antigo ao acessar o endereço 0xf800:0x8000 esperaria que o processador acessasse o endereço físico 0x000000, afinal, pra ele o endereço 0x100000 não existe. Mas o processador 80286 original não fazia nenhum tipo de correções nesse acesso, e programa antigo capotava ao acessar um endereço inválido sem ter muito o que fazer para corrigir o problema.

A solução veio na mais pura e cristalina gambiarra, o pessoal decidiu resolver isso direto na placa-mãe. Um gate AND lógico foi adicionado nesse último bit do barramento de endereços da memória (ou o vigésimo bit, ou o 20th address bit, e dai o nome A20), de modo que ele viria com uma porta lógica trabalhando como chave: se o bit de controle estiver zerado, o bit de memória era também zerado, caso o bit estivesse ligado, o endereço de memória (zero ou um) seria preservado.

E como é que ligamos ou desligamos esse bit? Ah, ai que a coisa começa a ficar divertida. O pessoal notou que o controlador 8042, responsável pelo teclado, tinha um pino sobrando. Então, foi soldado esse pino no A20 gate, e se você enviar os comandos certos para o controlador do teclado, você consegue habilitar ou desabilitar essa porta lógica. O diagrama lógico dessa parte do sistema fica assim portanto:

Ok, e como ativamos o A20 gate? Bom, eu não contei a história inteira ainda: não existe uma forma “uniforme e padronizada” de fazer essa ativação. Até porque, existem sistemas embarcados x86 que não possuem controladores de teclado, são acessíveis via rede, porta serial, ou algum outro tipo de método de entrada.

Bom, para encurtar a história, HOJE em dia nas CPUs mais modernas há uma função da BIOS para isso, a BIOS 15H função 0x2401. Se essa função não estiver disponível (se você invocar essa interrupção e a flag CF estiver setada) você precisa emitir comandos diretamente para o controlador do teclado (porta 0x64), ou usar comandos na porta der controle A (porta 0x92). Leia AQUI para quais sistemas já se tem mapeado quais métodos funcionam, o buraco é muito mais embaixo do que parece.

No nosso caso, o qemu-system-i386 aceita comandos da BIOS 15H. Então, será esse que usaremos. Deixei um comentário proposital para você completar o código caso a BIOS 15H não funcione para você:

...   
    ; Let's enable A20 gate
    mov ax, BIOS_INT_15H_ENABLE_A20
    int BIOS_INT_15H
    jnc a20_success

    ; write here code for Keyboard Controller or 0x92 Port!!!

a20_success:
...

Com sorte, após a execução da instrução INT, a flag CF estará zerada e o sistema entenderá que o gate A20 está ativo.

Agora é só mudar para o modo protegido e nossa vida está ganha? Tá achando que a vida é fácil jovem? Nada disso.

De fato, para mudar para o modo protegido, basta ativarmos o bit 0 no registrador CR0 (Control Register). Só que ao ativarmos o modo protegido, a gente recebe de brinde um monte de coisas legais que esse modo proporciona: endereçamento de 32bit, poderemos especificar endereços de memória onde o kernel vai rodar (Ring 0) ou o usuário (Ring 3), proteção de memória, onde indicamos quais áreas são somente leitura (para os códigos) e escrita (dados/pilha) e no futuro, até paginação!

O problema é que tudo isso que eu disse é configurável, e o processador não assume nada por default. Ao executar em modo protegido, o processador vai buscar o que pode ou não ser feito nesse modo em um registrador específico para esse fim, que armazena informações sobre o infame GDT. Aperte os cintos que a jornada vai ser turbulenta.

Global Descriptor Table

GDT significa Global Descriptor Table, ou tabela de descritores global. Cada entrada dessa tabela possui 8 bytes, portanto 64 bits. A interpretação da entrada depende do que ela se refere, e no caso vamos analisar entradas para código privilegiado de kernel para código e dados.

As informações em vermelho são a numeração dos bits da entrada, indo de 0 a 63. Note que as informações em verde e azul dizem respeito as informações de endereço base e limite da região de memória apontada por essa entrada. O limite tem então 20 bits (indo dos bits 0 a 15 e 48 a 51) e o endereço base 32 bits (indo dos bits 16 a 31, 32 a 39 e 56 a 63). Não me pergunte porque o endereço base não pode ser contíguo, por ex, dos bits 0 a 31, com certeza é coisa do projeto do processador (assim espero!)

Se você está atento, notou que o endereço base pode ter qualquer endereço dentro do espaço de endereçamento de 32bit, mas o limite só tem 20. Será que essa entrada não consegue representar todo os 4GB (2^32) que os 32 bits nos permitem? A resposta é que sim! Devemos usar esses valores em conjunto com o bit 55, o G na figura acima, que significa granularidade. Assim, caso setado, ele especifica que o limite é representado como em unidades de 4KB (multiplicando 4KB por 1MB - os 20 bits do limite, chegamos nos 4GB). Se esse bit estiver zerado, significa que a unidade é 1 byte, e portanto essa entrada do GDT endereça apenas 1MB.

Vamos verificar o restante dos campos dessa entrada:

• O bit 40 é o bit de acesso. Ele é usado pela CPU ao acessar o segmento, e coloca 0 quando o segmento é lido, ou 1 quando o segmento é escrito. Tentativas de escrever em um segmento somente leitura (como é o caso de segmento de código) tentará setar esse bit e falhará causando uma falha de segmentação ou page fault se a paginação já estiver habilitada.

• Os próximos 4 bits (41 a 44) dizem respeito ao tipo de segmento que essa entrada referencia. O bit 43 indica se esse é um segmento de código (1) ou dados (0). Se for um segmento de código, o bit 41 indica se esse segmento de código pode ser lido (1). Se for um segmento de dados/pilha, esse mesmo bit indica se esse segmento pode ser escrito (1). O bit 42, para segmentos de dados/pilha, indica a direção da expansão. Se estiver setado, indica que o segmento cresce para baixo, ou seja, que o offset do endereço é maior que o limite. Do contrário, endereço base + offset < limite, que é o nosso caso. Para entender isso é melhor verificar como é feita a tradução do segmento na figura abaixo:

  

• O bit 44 é setado, quando esse segmento é referente a segmentos de código ou dados (nosso caso). Do contrário, zero significa que é um segmento TSS (Task State Segment, será apresentado em algum momento futuro).

• Os bits 45 e 46 referem-se ao DPL (Descriptor Privilege Level). Você pode ter ouvindo falar dos anéis de privilégio de execução do código em outros sistemas operacionais. Quanto maior o nível, menor o privilégio. Por esse motivo, geralmente códigos do kernel rodam no nível 0 (bits 00) e código do usuário rodam no nível menos privilegiado, ou seja, 3 (bits 11). Por enquanto, rodaremos no nível 0. Códigos que executam em Ring 3 por exemplo não podem executar certas instruções, como IN/OUT (manipulação de portas de hardware).

• O bit 47 diz se o segmento está presente. Obviamente deixaremos esse bit setado para nossas entradas.

Os bits 52 a 55 são os bits de flags, definidos abaixo:

• O bit 52 é reservado, deixe este zerado.

• O bit 53 é o bit do modo longo (modo de 64 bits). Como estamos trabalhando como 32 bits, deixe esse bit zerado.

• O bit 54 indica se estamos trabalhando com 16 (bit zerado) ou 32 bits (bit setado). Pois é, é possível trabalhar no modo protegido em 16 bits (é o caso do processador 80286). No nosso caso, como estamos em modo protegido 32 bits, deixe esse bit setado.

• O bit 55 já foi explicado acima, é o bit de granularidade. Quando zerado, o segmento descrito por esse seletor possui no máximo 1MB, pois a unidade usada é de 1 byte. Caso contrário (nosso caso), a unidade é 4KB e nosso segmento pode ter tamanho máximo de 4GB.

No fim das contas, dado um endereço base de 32 bits, o limite de 20 bits (que pode ser armazenado em um registrador de 32 sem perdas) e os bytes de tipo e flags, é questão de coreografia de shifts e máscaras para acomodar tais valores no formato previsto do GDT.

Tudo o que foi dito até agora é referente a apenas UMA entrada da da tabela de descritores globais. Precisamos de algumas. Por enquanto definiremos três, mas já sabendo que no futuro vamos precisar de mais. Precisamos de um descritor nulo (os 64 bits da entrada zerados), por exigências da especificação do processador. Precisamos ainda de um descritor para o segmento de código do kernel e outro para o segmento de dados (no momento, os endereços físicos se sobrepõem, acessando os mesmos endereços de 0 a 4GB de memória). Depois, precisaremos de um descritor para o segmento de código do usuário e outro para o segmento de dados, no menor nível de privilégio (ring 3). Ainda haverá um descritor TSS, que auxilia na troca de contexto a nível de hardware. Por enquanto, apenas a entrada verde (descritor nulo) e as entradas pretas da imagem abaixo estão presentes no código atual.

O GDT é carregado através da instrução LGDT, e passamos o endereço de uma estrutura especial em memória de 48 bits. Essa estrutura possui os 16 primeiros bits relacionado a quantos bytes a tabela ocupa, e pode ser calculada como o número de entradas multiplicado pelo tamanho da entrada (8 bytes ou 64 bits). Os próximos 32 bits são o endereço em memória do início da tabela, conforme apresentado na figura acima.

Definimos algumas constantes em assembly para representar os dois segmentos, de código e dados do kernel.

%define GDT_KCS_LIMIT 0xfffff
%define GDT_KCS_BASE 0x00000000
%define GDT_KCS_MIDDLE_LIMIT  (GDT_KCS_LIMIT >> 16) & 0x0f ; lower 4 bits
%define GDT_KCS_FLAGS (1100b << 4)  ; 0 - 0 - (1) 32bit -  (1) 4Kb unit ; upper 4 bits

%define GDT_KCS_LIMIT_BYTES_0_1  GDT_KCS_LIMIT & 0xffff
%define GDT_KCS_BASE_BYTES_2_3  GDT_KCS_BASE & 0xffff
%define GDT_KCS_BASE_BYTE_4  (GDT_KCS_BASE >> 16) & 0xff
%define GDT_KCS_ACCESS_BYTE_5 10011010b ; (0) not used now - (1) readable - (0) user code can run here? - (1) code segment - (1) not system segment - (00) DPL/ring 0 - (1) present
%define GDT_KCS_MIDDLE_LIMIT_FLAGS_BYTE_6 GDT_KCS_MIDDLE_LIMIT | GDT_KCS_FLAGS
%define GDT_KCS_BASE_BYTE_7 (GDT_KCS_BASE >> 24) & 0xff

%define GDT_KDS_LIMIT GDT_KCS_LIMIT
%define GDT_KDS_BASE GDT_KCS_BASE
%define GDT_KDS_MIDDLE_LIMIT  GDT_KCS_MIDDLE_LIMIT
%define GDT_KDS_FLAGS GDT_KCS_FLAGS

%define GDT_KDS_LIMIT_BYTES_0_1  GDT_KCS_LIMIT_BYTES_0_1
%define GDT_KDS_BASE_BYTES_2_3  GDT_KCS_BASE_BYTES_2_3
%define GDT_KDS_BASE_BYTE_4  GDT_KCS_BASE_BYTE_4
%define GDT_KDS_ACCESS_BYTE_5 10010010b ; 0 (not used now) - (1) writable - (0) expand down - (0) data segment - (1) not system segment - (00) DPL/ring 0 - (1) present
%define GDT_KDS_MIDDLE_LIMIT_FLAGS_BYTE_6 GDT_KCS_MIDDLE_LIMIT_FLAGS_BYTE_6
%define GDT_KDS_BASE_BYTE_7 GDT_KCS_BASE_BYTE_7

Não se assuste com as operações de shift e máscara, não é tão difícil assim de entender. Por exemplo, a constante GDT_KCS_MIDDLE_LIMIT. Eu pretendo colocar esse valor nos primeiros 4 bits do byte representado pelos bits 48 a 55. O interesse é pegar os bits 16 a 19 do valor original de limite (0xfffff), que é o primeiro f mais a esquerda desse número. Seria então o 0xf0000. Mas esse f está na posição errada, ele precisa estar nos primeiros 4 bits, portanto a operação shift right 16: GDT_KCS_LIMIT >> 16. Por fim, chegamos ao valor 0x0000f, a operação está encerrada. Contudo, se o número fosse maior que 0xfffff (por exemplo, se alguém usasse todo os 32 bits de um registrador e definisse o limite como 0xffffffff), poderia haver bits mais significativos que não compõe o número original. Para garantir que isso não vai ocorrer, fazemos uma operação de AND bitwise com o valor 0x0f. Assim, preservamos os 4 primeiros bits e o restante é zerado. Então a operação abaixo

%define GDT_KCS_MIDDLE_LIMIT  (GDT_KCS_LIMIT >> 16) & 0x0f ; lower 4 bits

descara os 16 primeiros bits menos significativos, e desse novo número resultante, ele preserva os 4 primeiros bits menos significativos e zera os outros. Conseguimos então carregar esse byte nos bits 48 a 55 da entrada do GDT, sendo que os que possuem valor de fato são os bits 48 a 51, que são os bits de limite. Esse valor vai ser composto com a constante GDT_KCS_FLAGS para compor o valor do byte completo.

Outro ponto interessante de notar é que os valores de segmento de código do kernel são idênticos ao segmento de dados, com exceção do byte 5, que altera o tipo de segmento.

Definimos a estrutura do GDT, seus valores e o ponteiro para essa tabela no arquivo bootloader.asm da seguinte forma:

gdt:

gdt_null:
    dq 0

gdt_kcs:
    dw GDT_KCS_LIMIT_BYTES_0_1, GDT_KCS_BASE_BYTES_2_3
    db GDT_KCS_BASE_BYTE_4, GDT_KCS_ACCESS_BYTE_5 , GDT_KCS_MIDDLE_LIMIT_FLAGS_BYTE_6, GDT_KCS_BASE_BYTE_7

gdt_kds:
    dw GDT_KDS_LIMIT_BYTES_0_1, GDT_KDS_BASE_BYTES_2_3
    db GDT_KDS_BASE_BYTE_4, GDT_KDS_ACCESS_BYTE_5 , GDT_KDS_MIDDLE_LIMIT_FLAGS_BYTE_6, GDT_KDS_BASE_BYTE_7

gdt_end:

gdt_pointer:
    dw gdt_end - gdt - 1
    dd gdt+(NEW_BOOTLOADER_SEGMENT << 4)

Aqui também, sem surpresa. Temos o descritor nulo, e os descritores do segmento de código e dados do kernel, com base nas constantes que mostramos antes. Definimos então o ponteiro do gdt, definindo o tamanho em bytes e o ponteiro para a tabela. Mas temos uma pegadinha: note que o endereço foi adicionado a um valor. NEW_BOOTLOADER_SEGMENT é 0x8000, NEW_BOOTLOADER_SEGMENT << 4 é 0x80000. Isso é porque o GDT precisa do endereço absoluto na memória. Se usarmos só o endereço gdt, o assembly tentará calcular esse deslocamento relativo ao código atual. Isso só funcionaria se nosso código começasse no endereço 0, mas esse código é o bootloader, que movemos para o endereço 0x80000.

Não está no código, mas se você quisesse chumbar os valores direto, você teria algo do tipo.

gdt:

gdt_null:
    dq 0

gdt_kcs:
    dq 0x00cf9a000000ffff

gdt_kds:
    dq 0x00cf92000000ffff

gdt_end:

gdt_pointer:
    dw gdt_end - gdt - 1
    dd gdt+(NEW_BOOTLOADER_SEGMENT << 4)

Eu acho pior dessa forma pois é difícil decodificar esses magic numbers depois. Mas ai vai de você.

Para finalizar, temos que carregar o GDT, ativar o modo protegido, recarregar os registradores de segmentos para que eles apontem para os descritores do GDT e fazer um far jump para o kernel. Importante, as interrupções precisam estar desabilitadas para esse procedimento. E depois que pousarmos no modo protegido no kernel, não teremos mais interrupções da BIOS disponíveis, e estaremos por conta própria.

...
a20_success:
   ; clear interruptions. BIOS INT will not be accessible anymore!
    cli

    lgdt [gdt_pointer]

    mov eax, cr0
    or eax, 0x1
    mov cr0, eax

    mov ax, gdt_kds - gdt
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov ss, ax
    mov esp, (STACK_SEG_BOOTLOADER << 4) + STACK_POINTER_BOOTLOADER
    mov ebp, esp    

    jmp gdt_kcs - gdt:KERNEL_INIT

Se tudo der certo, o código do kernel já pode ser escrito em C/C++! Meu objetivo aqui é só saber se a configuração está certa, e estou escrevendo uma mensagem na tela. O arquivo kernel.cpp ficou assim.

#include "include/gdt.h"
#include "include/screen.h"

extern "C" void _start() {
  install_gdt();

  const char *kernelMsg = "Hello Protected Mode!";

  clear_screen(RED, YELLOW);

  printk((char *)kernelMsg, RED, YELLOW);

  while (true) {
    /* BUSY LOOP*/
  }
}

Ignorem o arquivo gdt.h e install_gdt() por enquanto. O código é simples: a gente define uma mensagem que será mostrada, limpamos a tela e escrevemos tal mensagem na tela. Depois, ficamos em um loop infinito. O extern “C” solicita ao compilador C++ para exportar o nome da função dessa forma mesmo _start, para o linker o encontrar. Isso porque no C++ existe um negócio chamado Name Mangling, para evitar o conflito e colisão de nomes as funções nos código objeto são alteradas. A função printk(char*, CharColors, CharColors) se torna _Z6printkPc10CharColorsS0_. Isso é suficiente para decodificar a função e seus argumentos, inclusive quando métodos de uma classe. O utilitário c++filt ajuda nessa decodificação, teste no seu shell os comandos abaixo, e você perceberá o padrão:

$ c++filt -n _Z12clear_screen10CharColorsS_
clear_screen(CharColors, CharColors)

$ c++filt -n _ZN3GDT17install_gdt_entryEjjhh
GDT::install_gdt_entry(unsigned int, unsigned int, unsigned char, unsigned char)

Para testar nos seus programas C++ compilados, execute o objdump -D e veja os nomes das funções e decodifique usando o c++filt.

Vale a pena verificar as funções clear_screen e printk, já que você estava atento e sabe que não podemos usar a BIOS INT 13H mais. Mas você tem sorte, se escrevermos em certos endereços da memória (no caso, a partir do endereço 0xB8000), o que for escrito lá aparece na tela. Por padrão, o vídeo vem configurado em modo texto, e cada dois bytes a partir do endereço 0xB8000 representam um caractere (primeiro byte) e seus atributos como cor de frente e fundo (segundo byte). Essa memória de vídeo pode ser encarada como uma matrix de 80 linhas por 25 colunas, dois bytes por elemento. Para limpar a tela como é feito na função clear_screen, basta criar dois laços e colocar o caracter ‘ ‘ na posição deseja, como fiz no código abaixo.

void clear_screen(CharColors foreground, CharColors background) {
  reset_current_position();
  for (int i = 0; i < NUM_ROWS; i++) {
    for (int j = 0; j < NUM_COLUMNS; j++) {
      *current_position++ = ' ';
      *current_position++ = get_char_attr(foreground, background);
    }
  }
  reset_current_position();
}

A função reset_current_position apenas posiciona o ponteiro para o valor inicial de SCREEN_POINTER (0xB8000).

inline void reset_current_position() {
  current_position = (char *)SCREEN_POINTER;
}

A função printk AINDA não é similar a função printf da libC, ou seja, ela não processa o formato da mensagem, mas isso será feito eventualmente. Atualmente só percorremos a string até encontrar o caractere nulo.

void printk(char *msg, CharColors foreground, CharColors background) {
  char *currentMsg = msg;
  do {
    if (*currentMsg == NULL) {
      break;
    }

    *current_position++ = *currentMsg++;
    *current_position++ = get_char_attr(foreground, background);
  } while (*currentMsg != NULL);
}

Por fim, a função get_char_attr prepara o byte de atributos, dado que especifiquemos as cores de frente e fundo do caractere. Os 4 primeiros bits (os menos significativos) são a cor de frente, e os quatro últimos (3 na verdade, o último bit mais significativo é uma outra coisa que não vem ao caso agora) representam a cor de fundo.

inline char get_char_attr(CharColors foreground, CharColors background) {
  return (foreground & 0x0f) | (background << 4);
}

Se são 4 bits, então podemos ter 16 combinações diferentes de cores? Isso ai. 0000 é preto, 0001 é azul, 0010 é verde e assim por diante. Fiz uma enumeração para facilitar nossa vida.

enum CharColors {
  BLACK,
  BLUE,
  GREEN,
  CYAN,
  RED,
  PURPLE,
  BROWN,
  GRAY,
  DARK_GRAY,
  LIGHT_BLUE,
  LIGHT_GREEN,
  LIGHT_CYAN,
  LIGHT_RED,
  LIGHT_PURPLE,
  YELLOW,
  WHITE
};

Só faltou o bode na sala, a função install_gdt() na função _start, no arquivo kernel.cpp. O GDT instalado no bootloader era temporário, mas nada o impedia de ser definitivo se adicionássemos as entradas de interesse lá. O problema na real é que o GDT lá estava na região de memória 0x80000, mesma região do bootloader. Depois que passamos o controle para o kernel, essa memória pode (e vai) ser sobrescrevida pelos códigos do kernel e usuário.

Uma solução seria copiar aquela região de memória para uma estrutura de dados nos arquivos novos do kernel, mas teríamos que saber o endereço correto, e isso pode mudar com alterações do arquivo bootloader.asm. E como no futuro vamos instalar um GDT parrudo, para usuários e TSS também, o melhor é recriarmos a instalação do GDT, mas agora usando os benefícios de uma linguagem de alto nível.

Assim, eu criei um arquivo de cabeçalho gdt.h para declarar duas classes: GDT e GDTPointer, conforme o código a seguir:

class GDT {
public:
  uint16_t limit_bytes_0_1 = 0;
  uint16_t base_address_bytes_2_3 = 0;
  uint8_t base_address_byte_4 = 0;
  uint8_t type_access_byte_5 = 0;
  uint8_t limit_flags_byte_6 = 0;
  uint8_t base_address_byte_7 = 0;

  void install_gdt_entry(uint32_t, uint32_t, uint8_t, uint8_t);
} __attribute__((__packed__));

class GDTPointer {
public:
  uint16_t size = 0;
  uint32_t gdt_entries_address = 0;
} __attribute__((__packed__));

Perceba que o GDT é muito “similar” à discussão que tivemos em assembly, mas agora com classes e método. A declaração __attribute__((__packed__)) solicita que o compilador gentilmente ignore o alinhamento dos tipos de dados da estrutura, ou seja, evita que o compilador adicione paddings. Se você não sabe do que eu estou falando, volte ao PDF do formato ELF, especificamente nesse trecho abaixo.

Enquanto nas estruturas do arquivo ELF é previsto que exista padding se necessário, de forma nenhuma isso pode ocorrer com nossa estrutura GDT, pois é esperado pelo hardware do processador que ela tenha esse formato rígido.

No arquivo gdt.cpp definimos as variáveis globais abaixo, garantindo portanto que essas variáveis estejam no domínio de memória do kernel.

GDT gdt_entries[GDT_ENTRIES];
GDTPointer gdtp;

A instalação de uma entrada é aquela coreografa de shifts e máscaras dito anteriormente.

void GDT::install_gdt_entry(uint32_t base_address, uint32_t limit, uint8_t type,
                            uint8_t flags) {
  this->limit_bytes_0_1 = limit & 0xffff;
  this->base_address_bytes_2_3 = base_address & 0xffff;
  this->base_address_byte_4 = (base_address >> 16) & 0xff;
  this->type_access_byte_5 = type;
  this->limit_flags_byte_6 = (limit >> 16) & 0xf;
  this->limit_flags_byte_6 |= flags;
  this->base_address_byte_7 = (base_address >> 24) & 0xff;
}

A função install_gdt, é, portanto, instalar as três primeiras entradas do GDT (descritores nulo, código e dados do kernel), carregar a estrutura do GDTPointer e executar as instruções assembly inline para instalar esse novo GDT.

void install_gdt() {
  // NULL descriptor (gdt_entries[GDT_NULL_SEL]) is constructed by default

  // Kernel Code segment
  gdt_entries[GDT_KCS_SEL].install_gdt_entry(
      0x00000000, 0xfffff,
      GDT_ACCESS_CODE_SEG_READ | GDT_TYPE_CODE_SEG_READ |
          GDT_TYPE_CODE_SEG_NOT_CONFIRMING | GDT_TYPE_CODE_SEG |
          GDT_TYPE_DESCRIPTOR_CODE_OR_DATA | GDT_RING_00 | GDT_TYPE_PRESENT,
      GDT_FLAG_USER_DEFINED | GDT_LONG_MODE_DISABLED | GDT_32BIT_FLAG |
          GDT_GRANULARITY_FLAG);
  // Kernel Data segment
  gdt_entries[GDT_KDS_SEL].install_gdt_entry(
      0x00000000, 0xfffff,
      GDT_ACCESS_DATA_SEG_WRITE | GDT_TYPE_DATA_SEG_WRITE |
          GDT_TYPE_DATA_SEG_GROW_UPSIDE | GDT_TYPE_DATA_SEG |
          GDT_TYPE_DESCRIPTOR_CODE_OR_DATA | GDT_RING_00 | GDT_TYPE_PRESENT,
      GDT_FLAG_USER_DEFINED | GDT_LONG_MODE_DISABLED | GDT_32BIT_FLAG |
          GDT_GRANULARITY_FLAG);

  // User code, data segments and TSS goes here

  // Load GDT
  gdtp.size = (uint16_t)(sizeof(GDT) * GDT_ENTRIES);
  gdtp.gdt_entries_address = (uint32_t)gdt_entries;

  asm("lgdt %0" : : "m"(gdtp));
  asm("ljmp %0, $continue_load_gdt_register \n\t"
      "continue_load_gdt_register: \n\t" ::"i"(GDT_KCS_SEL * 0x8));
  asm("mov %0, %%eax \n\t"
      "mov %%ax, %%ds \n\t"
      "mov %%ax, %%es \n\t"
      "mov %%ax, %%fs \n\t"
      "mov %%ax, %%gs \n\t"
      "mov %%ax, %%ss \n\t" ::"i"(GDT_KDS_SEL * 0x8));
}

Se você tem dúvidas de que isso funciona, experimente comentar as chamadas gdt_entries[GDT_KCS_SEL].install_gdt_entry e gdt_entries[GDT_KDS_SEL].install_gdt_entry e execute o código, para verificar uma falha de segmentação ao vivo e em cores, a nível de kernel!

Fiz uma pequena alteração no Makefile, pois agora temos 3 arquivos cpp do kernel. Precisamos compilarmos e linkarmos, garantindo que o arquivo kernel.o seja o primeiro para que ele fique no endereço 0x1000 como inicialmente previsto.

OBJS:=screen.o gdt.o
OBJ_LINK_LIST:=kernel.o $(OBJS)

Para os arquivos .cpp do kernel, precisamos indicar ao compilador que ele de forma alguma use runtime, stdlib ou similares, já que não há suporte a tais firulas quando o computador inicia.

%.o: $(SRCDIR)/%.cpp
	g++ -g -m32 -c $< -o $(OUTPUTDIR)/$@ -ffreestanding -O2 -Wall -Wextra -fno-exceptions -nostdlib -fno-rtti -nostartfiles

...

kernel:  $(OBJ_LINK_LIST)
	cd $(OUTPUTDIR) && ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x1000  -o $@ $(OBJ_LINK_LIST)

Por fim, todo aquele malabarismo para fazer o gdb mostrar as informações em modo real já não nos servirá (você pode voltar sempre que precisar debugar o bootloader). O arquivo debug_BoringOS.sh fica bem mais simples agora:

gdb -ex 'target remote localhost:1234' -ex 'hbreak *0x7c00' -ex 'set confirm off' -ex "add-symbol-file $CURRDIR/build/bootloader 0x80000" -ex "add-symbol-file $CURRDIR/build/kernel" -ex 'set confirm on' -ex 'c'

Contudo, ainda acho a visualização default do gdb bem ruim. Por isso, criei um arquivo ~/.gdbinit e coloquei esse código DAQUI. Fica bem melhor para ver as informações. Essa visualização fica mais ou menos como a imagem abaixo.

Se tudo deu certo, você será agraciado com a seguinte tela no QEMU.

Ufa, longa jornada hein? Agora é sobra e água fresca? Nada disso. As interrupções ainda desabilitadas, e assim que as habilitarmos, se não tivermos instalado o IDT (Interruption Descriptor Table, uma tabela de descritores muito parecido com o GDT, mas para o tratamento das interrupções), qualquer interrupçãozinha disparada (por exemplo, teclar uma tecla no teclado) vai fazer seu kernel capotar. Tem muita coisa a ser feita ainda, mas não nesse artigo. Acesso o código descrito até o momento AQUI.

Quem constrói os construtores?

Esse artigo terminou, mas fiz algumas tentativas infrutíferas que quero compartilhar. Inicialmente havia colocado um construtor no GDTPointer da seguinte forma:

class GDTPointer {
public:
  uint16_t size = 0;
  uint32_t gdt_entries_address = 0;

  GDTPointer(uint16_t size, uint32_t address) {
    this->size = size;
    this->gdt_entries_address = address;
  }
} __attribute__((__packed__));

Coisa boba né? Depois, alterei a declaração do objeto GDTPointer no arquivo gdt.cpp da seguinte forma:

GDTPointer gdtp((uint16_t)(sizeof(GDT) * GDT_ENTRIES), (uint32_t)gdt_entries);

Nada demais. Mas ao fazer isso, o código para de funcionar. O motivo inicial é que apareceu uma função no endereço 0x1000, e a função _start foi deslocada:

Symbol table '.symtab' contains 22 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS gdt.cpp
     2: 00001228     0 NOTYPE  LOCAL  DEFAULT    1 continue_load_gd[...]
     3: 00001000    35 FUNC    LOCAL  DEFAULT    1 _GLOBAL__sub_I_g[...]
     4: 00000000     0 FILE    LOCAL  DEFAULT  ABS kernel.cpp
     5: 00000000     0 FILE    LOCAL  DEFAULT  ABS screen.cpp
     6: 00000000     0 FILE    LOCAL  DEFAULT  ABS 
     7: 00003ff4     0 OBJECT  LOCAL  DEFAULT    5 _GLOBAL_OFFSET_TABLE_
     8: 000010e0   157 FUNC    GLOBAL DEFAULT    1 _Z12clear_screen[...]
     9: 0000117d     0 FUNC    GLOBAL HIDDEN     1 __x86.get_pc_thunk.ax
    10: 0000400c    24 OBJECT  GLOBAL DEFAULT    7 gdt_entries
    11: 00001181     0 FUNC    GLOBAL HIDDEN     1 __x86.get_pc_thunk.dx
    12: 00001030    56 FUNC    GLOBAL DEFAULT    1 _start
    13: 00001068     0 FUNC    GLOBAL HIDDEN     1 __x86.get_pc_thunk.bx
    14: 00004000     4 OBJECT  GLOBAL DEFAULT    6 current_position
    15: 00004004     0 NOTYPE  GLOBAL DEFAULT    7 __bss_start

Note que agora há a função _GLOBAL__sub_I_gdt_entries no endereço 0x1000, e a função _start foi para o endereço 0x1030. Pelo nome nem parece ser o construtor de GDTPointer. Poderíamos alterar o createimage.cpp para ler a tabela de símbolos e obter esse novo endereço e escrever no bootloader, tal qual fazemos com a variável os_size, mas o problema é mais profundo que isso. Na verdade, só com essas alterações, se você mudar jmp gdt_kcs - gdt:0x1000 para jmp gdt_kcs - gdt:0x1030, o código não funciona, e o motivo é que o construtor do GDTPointer não é invocado.

Para usarmos construtores C++, até no kernel, precisamos fazer algumas alterações como dito AQUI, tal como fornecer arquivos crti.asm e crtn.asm. Ainda precisamos dos arquivos crtbegin.o e crtend.o fornecidos pelo compilador. Até instalei o pacote g++-multilib pois do contrário ele usará a versão de 64 bits por padrão e o linker irá reclamar:

sudo apt-get install g++-multilib

Fazendo o código abaixo (adaptado DAQUI):

SRCDIR=src
OUTPUTDIR=build

OBJS:=screen.o gdt.o

CRTI_OBJ=crti.o
CRTBEGIN_OBJ:=$(shell g++ -m32 $(CFLAGS) -print-file-name=crtbegin.o)
CRTEND_OBJ:=$(shell g++ -m32 $(CFLAGS) -print-file-name=crtend.o)
CRTN_OBJ=crtn.o

OBJ_LINK_LIST:=$(CRTI_OBJ) $(CRTBEGIN_OBJ) $(OBJS) $(CRTEND_OBJ) $(CRTN_OBJ)

all: $(OUTPUTDIR) kernel bootloader createimage
	./$(OUTPUTDIR)/createimage --extended ./$(OUTPUTDIR)/bootloader ./$(OUTPUTDIR)/kernel

$(OUTPUTDIR):
	mkdir $@

%.o: $(SRCDIR)/%.asm
	nasm -wall -O2 -f elf32 -F dwarf -g -o $(OUTPUTDIR)/$@ $<

%.o: $(SRCDIR)/%.cpp
	g++ -g -m32 -c $< -o $(OUTPUTDIR)/$@ -ffreestanding -O2 -Wall -Wextra -fno-exceptions -nostdlib -fno-rtti -nostartfiles -lg++

bootloader: bootloader.o
	ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x0 -o $(OUTPUTDIR)/$@ $(OUTPUTDIR)/$<

kernel:  kernel.o $(OBJ_LINK_LIST)
	cd $(OUTPUTDIR) && ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x1000 --section-start .init=0x5000  -o $@ kernel.o $(OBJ_LINK_LIST)

createimage: $(SRCDIR)/createimage.cpp
	g++ -o $(OUTPUTDIR)/$@ $<

clean:
	rm -rf $(OUTPUTDIR)/*

Ainda assim não funcionou, o linker não encontra a função _init():

$ make clean && make
rm -rf build/*
g++ -g -m32 -c src/kernel.cpp -o build/kernel.o -ffreestanding -O2 -Wall -Wextra -fno-exceptions -nostdlib -fno-rtti -nostartfiles -lg++
nasm -wall -O2 -f elf32 -F dwarf -g -o build/crti.o src/crti.asm
g++ -g -m32 -c src/screen.cpp -o build/screen.o -ffreestanding -O2 -Wall -Wextra -fno-exceptions -nostdlib -fno-rtti -nostartfiles -lg++
g++ -g -m32 -c src/gdt.cpp -o build/gdt.o -ffreestanding -O2 -Wall -Wextra -fno-exceptions -nostdlib -fno-rtti -nostartfiles -lg++
nasm -wall -O2 -f elf32 -F dwarf -g -o build/crtn.o src/crtn.asm
cd build && ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x1000 --section-start .init=0x5000  -o kernel kernel.o crti.o /usr/lib/gcc/x86_64-linux-gnu/13/32/crtbegin.o screen.o gdt.o /usr/lib/gcc/x86_64-linux-gnu/13/32/crtend.o crtn.o
ld: warning: crtn.o: missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
ld: kernel.o: in function `_start':
/home/p_8410/projects/boring-os/src/kernel.cpp:7:(.text+0x10): undefined reference to `_init()'
make: *** [Makefile:29: kernel] Error 1

Deve ser coisa boba, mas como não consegui resolver isso em um tempo razoável, se alguém souber como resolver isso, por favor me avise!

Anterior

Próximo

Logo logo o Dummy Kernel (veja o post anterior) vai dar lugar a um Kernel que faça algo de verdade. E quando isso acontecer, o arquivo não vai mais ser escrito em Assembly, mas em C/C++. Conforme o projeto vai ficando mais complexo, o formato binário que estamos usando deixa de ser atraente da forma como está, pois este formato perde os símbolos e outras informações relevantes (lembra que para debugar estamos usando o arquivo objeto .o? Pois é).

O P1 espera que você consiga extrair o “código” dos arquivos ELF do bootloader e do Kernel, juntar os dois e criar uma nova imagem bootável. Obviamente há um caráter pedagógico aqui, você pode aprender muito lendo o belo manual e entender do que se trata cada informação. Faremos isso, mas antes de prosseguir, informo que é possível fazer de uma forma mais fácil: você pode usar o utilitário objcopy, extrair o conteúdo relevante dos arquivos executáveis ELF, juntar os dois e depois sobrescrever os bytes 2, 3, 4 e 5 desse arquivo com o tamanho do kernel (talvez usando awk? É só uma sugestão :D ), considerando a unidade número de setores do disco (considere ainda o byte order, que no caso do x86 é little endian). Se você fizer isso, parabéns, trabalho concluído (mas você não ganharia nota). Até por isso, deixo isso como exercício.

Nós vamos pelo caminho mais difícil: Faremos um programa em C/C++ para abrir os arquivos binários ELF, extrair as informações, colar elas mal e porcamente com cuspe e maisena e gerar uma imagem bootável, tal qual é pregado no P1.

Antes, vamos deixar nosso kernel um pouquinho mais complexo. Vamos adicionar seções .bss, .data e .rdata. Isso nos obrigará a fazer um parser mais elaborado. O final do arquivo kernel.asm fica assim:

...
big_big_msg db "Big Big Dummy Kernel Loaded!", CARRIER_RETURN, LINE_FEED, NULL_CHARACTER   


SECTION .bss
bsssegtest  resb 50

SECTION .data
datasegtest db 'X'

SECTION .rdata
teste db 'readonlydata'

Depois veremos no que isso resultará.

O primeiro passo é alterar o Makefile para que ele gere arquivos ELF. Os trechos de geração os targets booloader e kernel eram assim:

bootloader: bootloader.o
	ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x0 -s --oformat binary -o $(OUTPUTDIR)/$@ $(OUTPUTDIR)/$<

kernel: kernel.o
	ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x1000 -s --oformat binary -o $(OUTPUTDIR)/$@ $(OUTPUTDIR)/$<

e ficou assim:

bootloader: bootloader.o
	ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x0 -o $(OUTPUTDIR)/$@ $(OUTPUTDIR)/$<

kernel: kernel.o
	ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x1000 -o $(OUTPUTDIR)/$@ $(OUTPUTDIR)/$<

Mais simples né? Isso porque o formato ELF é o padrão no Linux. Além disso, removemos a flag -s pois isso remove os símbolos de debug, o que está longe de ser nosso objetivo.

Aproveitando que estamos no Makefile, vamos criar o target createimage, que é um programa que lerá os ELFs e os unirá.

createimage: $(SRCDIR)/createimage.cpp
	g++ -o $(OUTPUTDIR)/$@ $<

Aqui, uma diferença em relação ao código fornecido no trabalho P1: lá, esse programa era escrito em C. Até para diferenciar, resolvi fazer diferente.

Pensei em fazer em Rust, mas lembrei que não sei Rust, pareceu pouco produtivo aprender outra linguagem de programação para fazer só isso (NOTA DO EDITOR: Rust será aprendida, eventualmente. Mas não agora e não para isso).

Parti então para o Python, e a manipulação de arquivos binários foi bem frustrante. Possível, mas frustrante. Não vale o esforço. Decidi fazer então com um mix de C e C++ (ou como dizia meu professor, C+/-).

Não abri o código original, o código está estruturado para que os alunos alterem partes específicas e completem as funções:

read_exec_file(): Reads in an executable file in ELF format.
write_bootblock(): Writes the bootblock to the image file.
write_kernel(): Writes the kernel to the image file.
count_kernel_sectors(): Counts the number of sectors in the kernel.
record_kernel_sectors(): Tells the bootloader how many sectors the kernel has.
extended_opt(): Prints the information for --extended option.

Eu não entendo por exemplo porque há a função extended_opt, e o que é feito de diferente se a função —extended não for usada. Por mim isso nem seria uma opção mas o comportamento padrão do código. Também não sei quais parâmetros as funções exigem, por isso vou fazer conforme as vozes da minha cabeça. Mas não vou brigar com a banca, tentarei fazer seguindo essas instruções e por isso, em vez de escrever direto na saída padrão (usando cout do C++), escreverei em uma ostringstream, servindo como um string buffer, e só ao final do processo mando isso para o console.

Ok, vamos lá. Para abrir o arquivo ELF, entender sua estrutura para poder extrair as informações necessárias, você precisa conhecer as entranhas do cidadão. É importante ler a documentação, mas adianto que não é necessário ler tudo. Uma boa parte do conteúdo diz respeito a como um Sistema Operacional deve “ler” para carregar o executável na memória, incluindo bibliotecas compartilhadas, ligação dinâmica, a biblioteca padrão do C… Crianças, nada disso está disponível quando a máquina liga, não há um SO que carregará tais componentes, afinal, nós somos o SO! Então, precisamos de duas coisas: ler o cabeçalho do arquivo ELF, encontrar os cabeçalhos do programa e com base neles, carregar os segmentos de interesse. Nem todo segmento possui um código executável, então precisamos também identificar isso. Com base no que eu disse, vamos dar uma olhada no conteúdo dos arquivos ELF usando o utilitário readelf.

Começando pelo Bootloader:

readelf -a ./build/bootloader
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          5132 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         9
  Section header string table index: 8

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 001000 0000a0 00  AX  0   0 16
  [ 2] .debug_aranges    PROGBITS        00000000 0010a0 000020 00      0   0  1
  [ 3] .debug_info       PROGBITS        00000000 0010c0 000069 00      0   0  1
  [ 4] .debug_abbrev     PROGBITS        00000000 001129 00001d 00      0   0  1
  [ 5] .debug_line       PROGBITS        00000000 001146 00007f 00      0   0  1
  [ 6] .symtab           SYMTAB          00000000 0011c8 000120 10      7  14  4
  [ 7] .strtab           STRTAB          00000000 0012e8 0000cc 00      0   0  1
  [ 8] .shstrtab         STRTAB          00000000 0013b4 000056 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00000000 0x00000000 0x000a0 0x000a0 R E 0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .text 

There is no dynamic section in this file.

There are no relocations in this file.
No processor specific unwind information to decode

Symbol table '.symtab' contains 18 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS src/bootloader.asm
     2: 00000002     2 OBJECT  LOCAL  DEFAULT    1 os_size
     3: 00000006     1 OBJECT  LOCAL  DEFAULT    1 disk_index
     4: 00000007     1 OBJECT  LOCAL  DEFAULT    1 sectors_per_track
     5: 00000008     1 OBJECT  LOCAL  DEFAULT    1 number_of_heads
     6: 00000009     2 OBJECT  LOCAL  DEFAULT    1 current_lba_address
     7: 0000000b     0 NOTYPE  LOCAL  DEFAULT    1 load_kernel
     8: 0000002f     0 NOTYPE  LOCAL  DEFAULT    1 before_jump
     9: 00000034     0 NOTYPE  LOCAL  DEFAULT    1 new_boot_region
    10: 00000039     0 NOTYPE  LOCAL  DEFAULT    1 reset_disk
    11: 00000041     0 NOTYPE  LOCAL  DEFAULT    1 get_disk_parameters
    12: 00000061     0 NOTYPE  LOCAL  DEFAULT    1 read_sector
    13: 0000009b     0 NOTYPE  LOCAL  DEFAULT    1 end_read_sector
    14: 00000000     0 NOTYPE  GLOBAL DEFAULT    1 _start
    15: 00001000     0 NOTYPE  GLOBAL DEFAULT    1 __bss_start
    16: 00001000     0 NOTYPE  GLOBAL DEFAULT    1 _edata
    17: 00001000     0 NOTYPE  GLOBAL DEFAULT    1 _end

No version information found in this file.

Do que nos interessa, é ler esse cabeçalho (ELF Header). Nele, perceba a informação Start of program headers: 52 (bytes into file). Isso significa que, partindo do primeiro byte desse arquivo ELF, se eu iniciar a leitura do offset 52 eu começarei a ler os dados dos cabeçalhos do programa. E quantos bytes eu devo ler para identificar todos os cabeçalhos do programa? Isso está na informação Size of program headers: 32 (bytes).

Ok, e como lemos esse cabeçalho ELF? O manual apresenta a estrutura que podemos usar:

Então, você pode copiar essa estrutura ai, OOOOOOU você faz igual eu fiz e uso a estrutura declarada no arquivo elf.h. No arquivo C/C++ basta declarar:

#include <elf.h>

Declarei portanto a função read_exec_file que recebe o std::ifstream exec_file (lembre-se que estou usando C++). Eu declaro uma variável local Elf32_Ehdr ehdr, reservando portanto o espaço para lermos os dados do cabeçalho do arquivo. Ao lermos a quantidade de bytes equivalente ao tamanho da estrutura (sizeof(Elf32_Ehdr)) e armazenando na variável ehdr, temos os dados que precisamos.

Ai basta rebobinar o arquivo (sabe o que é isso jovem?) e, começando do início do arquivo (std::ios_base::beg), posicionamos a cabeça de leitura imaginária bem no ponto onde começam os cabeçalhos do programa (ehdr.e_phoff). Essa parte inicial fica portanto assim:

  exec_file.read(reinterpret_cast<char *>(&ehdr), sizeof(Elf32_Ehdr));
  exec_file.seekg(ehdr.e_phoff, std::ios_base::beg);

Porque usamos o reinterpret_cast? A função read de um objeto std::ifstream espera receber um ponteiro de char. Poderíamos sim usar um cast normal, já que a estrutura Elf32_Ehdr não é um objeto C/C++ com comportamentos etc. Então, (char *)&ehdr funcionaria, mas como estamos no maravilho mundo do C++, eu quero que a leitura comece a cuspir bytes na estrutura sem reclamações adicionais. Para mais informações, veja aqui.

Agora que estamos com a bala na agulha para ler os cabeçalhos de programa, como fazemos isso? Vamos voltar à saída do nosso bom e velho readelf do bootloader:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00000000 0x00000000 0x000a0 0x000a0 R E 0x1000

Não parece tão complicado certo? Não tão rápido. Vamos ver os mesmos dados, mas para o kernel:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x000b4 0x000b4 R   0x1000
  LOAD           0x001000 0x00001000 0x00001000 0x60031 0x60031 R E 0x1000
  LOAD           0x062000 0x00062000 0x00062000 0x0000c 0x0000c R   0x1000
  LOAD           0x06200c 0x0006300c 0x0006300c 0x00001 0x00038 RW  0x1000

Hum, ai começa a complicar. O bootloader possui 1 cabeçalho de programa, enquanto o kernel possui 4. Um dos motivos dessa diferença é justamente aquelas seções que havíamos adicionado anteriormente, lembra? As seções .bss, .data e .rdata. Como ainda não apresentamos a saída do readelf para o kernel, faremos isso agora.

readelf -a ./build/kernel
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x1000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          402300 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         12
  Section header string table index: 11

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00001000 001000 060031 00  AX  0   0 16
  [ 2] .rdata            PROGBITS        00062000 062000 00000c 00   A  0   0  1
  [ 3] .data             PROGBITS        0006300c 06200c 000001 00  WA  0   0  4
  [ 4] .bss              NOBITS          00063010 06200d 000034 00  WA  0   0  4
  [ 5] .debug_aranges    PROGBITS        00000000 06200d 000020 00      0   0  1
  [ 6] .debug_info       PROGBITS        00000000 06202d 000065 00      0   0  1
  [ 7] .debug_abbrev     PROGBITS        00000000 062092 00001d 00      0   0  1
  [ 8] .debug_line       PROGBITS        00000000 0620af 00008f 00      0   0  1
  [ 9] .symtab           SYMTAB          00000000 062140 000130 10     10  15  4
  [10] .strtab           STRTAB          00000000 062270 0000a1 00      0   0  1
  [11] .shstrtab         STRTAB          00000000 062311 000068 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x000b4 0x000b4 R   0x1000
  LOAD           0x001000 0x00001000 0x00001000 0x60031 0x60031 R E 0x1000
  LOAD           0x062000 0x00062000 0x00062000 0x0000c 0x0000c R   0x1000
  LOAD           0x06200c 0x0006300c 0x0006300c 0x00001 0x00038 RW  0x1000

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .text 
   02     .rdata 
   03     .data .bss 

There is no dynamic section in this file.

There are no relocations in this file.
No processor specific unwind information to decode

Symbol table '.symtab' contains 19 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS src/kernel.asm
     2: 00001002     0 NOTYPE  LOCAL  DEFAULT    1 print_char
     3: 00001016     0 NOTYPE  LOCAL  DEFAULT    1 print_string
     4: 00001020     0 NOTYPE  LOCAL  DEFAULT    1 loop_print_string
     5: 0000102c     0 NOTYPE  LOCAL  DEFAULT    1 end_print_string
     6: 00001031     0 NOTYPE  LOCAL  DEFAULT    1 kernel_entry
     7: 00001046     1 OBJECT  LOCAL  DEFAULT    1 msg
     8: 00031000     0 NOTYPE  LOCAL  DEFAULT    1 big_dummy_kernel
     9: 00031015     1 OBJECT  LOCAL  DEFAULT    1 big_msg
    10: 00061000     0 NOTYPE  LOCAL  DEFAULT    1 big_big_dummy_kernel
    11: 00061012     1 OBJECT  LOCAL  DEFAULT    1 big_big_msg
    12: 00063010     1 OBJECT  LOCAL  DEFAULT    4 bsssegtest
    13: 0006300c     1 OBJECT  LOCAL  DEFAULT    3 datasegtest
    14: 00062000     1 OBJECT  LOCAL  DEFAULT    2 teste
    15: 00001000     0 NOTYPE  GLOBAL DEFAULT    1 _start
    16: 00063010     0 NOTYPE  GLOBAL DEFAULT    4 __bss_start
    17: 0006300d     0 NOTYPE  GLOBAL DEFAULT    3 _edata
    18: 00063044     0 NOTYPE  GLOBAL DEFAULT    4 _end

No version information found in this file.

Note que temos informações ligando os cabeçalhos de programa às seções. Veja abaixo:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x000b4 0x000b4 R   0x1000
  LOAD           0x001000 0x00001000 0x00001000 0x60031 0x60031 R E 0x1000
  LOAD           0x062000 0x00062000 0x00062000 0x0000c 0x0000c R   0x1000
  LOAD           0x06200c 0x0006300c 0x0006300c 0x00001 0x00038 RW  0x1000

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .text 
   02     .rdata 
   03     .data .bss 

Então, temos 4 cabeçalhos de programa, e 4 seções de segmento. As seções 01, 02 e 03 são nossas conhecidas. Note também as flags no cabeçalho de programa: a seção 01 .text tem flag R E (Leitura e Execução), a seção 02 .rdata é uma seção somente leitura (dai o nome, rdata é referente a read only data) e possui somente a flag R, e a seção 03 .data .bss é auto explicativa, e devemos poder ler escrever dela, e dai também as flags RW. A única observação interessante é a função .bss, que apenas instrui quantos bytes devem ser reservados na memória para dados não inicializados. Como isso é apenas uma instrução, ele não consome dados no FileSiz do segmento (esse 0x00001 byte é referente à variavel datasegtest no segmento .data) mas instrui que a memória alocada seja feita para isso (MemSiz igual a 0x00038 contempla a memória tanto para as seções .data quanto para .bss).

Mas e quanto ao segmento de seção 00? Se você notar o offset está 0x000000 e possui MemSiz/FileSiz igual a 0xb4. O que é isso afinal? Bom, se você notar bem, Isso é justamente os dados ocupados pelo ELF Header ( sizeof(Elf32_Ehdr) = 52 bytes) juntamente com os 4 cabeçalhos de programa, o próprio incluso. Como sizeof(Elf32_Phdr) = 32 bytes, temos que 52 + 4 * 32 = 180 = 0xb4! Então, a regra é que se o cabeçalho de programa tiver offset igual a zero, ele não é um código que deve ser extraído do arquivo ELF e nesse caso o ignoramos. Por que isso não apareceu no bootloader, eu não sei dizer.

Como o cabeçalho ELF já possui quantos cabeçalhos de programas há (Number of program headers: 4), está bem fácil fazer a leitura desses caras. Basta iterar pelo campo e_phnum da estrutura Elf32_Ehdr e ler a estrutura Elf32_Phdr nos mesmos moldes que fizemos anteriores. No fim, a função read_exec_file retorna um vetor de Elf32_Phdr. A função completa fica assim:

std::vector<Elf32_Phdr> read_exec_file(std::ifstream &exec_file) {
  Elf32_Ehdr ehdr;
  exec_file.read(reinterpret_cast<char *>(&ehdr), sizeof(Elf32_Ehdr));
  exec_file.seekg(ehdr.e_phoff, std::ios_base::beg);
  std::vector<Elf32_Phdr> program_headers;
  for (int i = 0; i < ehdr.e_phnum; i++) {
    Elf32_Phdr ph;
    exec_file.read(reinterpret_cast<char *>(&ph), sizeof(Elf32_Phdr));

    if (ph.p_offset > 0) {
      /*offset 0 has ELF Header and Program Headers, it is not a Executable
       Code*/
      program_headers.insert(program_headers.end(), ph);
    }
  }
  return program_headers;
}

Com o vetor Elf32_Phdr em mãos, o trabalho é iterar por esse vetor, e para cada cabeçalho, localizar o programa no ELF (campo p_offset de Elf32_Phdr) e ler os bytes disponíveis (campo p_filesz). Jogamos isso em um vetor de bytes (usei o tipo u_int8_t, mas poderia ser char também). Se p_memsz for maior que p_filesz, então precisamos alocar mais espaço (caso da seção .bss). Outra informação importante é que os endereços dos cabeçalhos de programa estão ordenados. Se dado um cabeçalho de programa que não seja o último, se seu PhysAddr + MemSiz for menor que o PhysAddr do próximo cabeçalho de programa, isso significa que há um espaço de padding que precisa ser incluído entre os conteúdos. Além disso, se for o último cabeçalho de programa e ele tiver menos de 512 bytes, fazemos um padding para atingir esse valor também.

A função de extrair os segmentos para um vetor de bytes ficou assim:

std::vector<u_int8_t> extract_segments(std::string exec_path,
                                       std::vector<Elf32_Phdr> ph,
                                       std::ifstream &exec_file,
                                       std::ostringstream &extended_string) {
  std::vector<u_int8_t> exec_bytes;

  extended_string << "0x" << std::hex << std::setw(4) << std::setfill('0')
                  << ph[0].p_vaddr << ": " << exec_path << std::endl;

  for (int i = 0; i < ph.size(); i++) {
    extended_string << "\tsegment " << i << std::endl;
    extended_string << "\t\toffset 0x" << std::hex << std::setw(4)
                    << std::setfill('0') << ph[i].p_offset << "\t vaddr 0x"
                    << std::hex << std::setw(4) << std::setfill('0')
                    << ph[i].p_vaddr << std::endl;
    extended_string << "\t\tfilesz 0x" << std::hex << std::setw(4)
                    << std::setfill('0') << ph[i].p_filesz << "\t memsz 0x"
                    << std::hex << std::setw(4) << std::setfill('0')
                    << ph[i].p_memsz << std::endl;

    exec_file.seekg(ph[i].p_offset, std::ios_base::beg);
    uint8_t buff[ph[i].p_filesz];
    exec_file.read(reinterpret_cast<char *>(buff), ph[i].p_filesz);
    exec_bytes.insert(exec_bytes.end(), buff, buff + ph[i].p_filesz);

    if (ph[i].p_filesz < ph[i].p_memsz) {
      exec_bytes.insert(exec_bytes.end(), ph[i].p_memsz - ph[i].p_filesz,
                        uint8_t(0));
    }

    if (i != ph.size() - 1 &&
        ph[i].p_vaddr + ph[i].p_memsz < ph[i + 1].p_vaddr) {
      exec_bytes.insert(exec_bytes.end(),
                        ph[i + 1].p_vaddr - (ph[i].p_vaddr + ph[i].p_memsz),
                        uint8_t(0));
      extended_string << "\t\tpadding up to 0x" << std::hex << std::setw(4)
                      << std::setfill('0') << ph[i + 1].p_vaddr << std::endl;
    } else if (i == ph.size() - 1 && exec_bytes.size() % SECTOR_SIZE > 0) {
      extended_string << "\t\tpadding up to 0x" << std::hex << std::setw(4)
                      << std::setfill('0')
                      << ph[i].p_vaddr + ph[i].p_memsz +
                             (SECTOR_SIZE - (exec_bytes.size() % SECTOR_SIZE))
                      << std::endl;
      exec_bytes.insert(exec_bytes.end(), SECTOR_SIZE - (exec_bytes.size() % SECTOR_SIZE),
                        uint8_t(0));
    }
  }

  return exec_bytes;
}

Acabamos com dois vetores de bytes, um representando o binário do bootloader e outro representando o binário do kernel. Precisamos agora ler quantos setores o binário do kernel possui e escrever essa informação, na posição correta no bootloader. Começando então pela contagem dos bytes do kernel, não há muito segredo. Dividimos o número de bytes do kernel por 512 (tamanho de um setor) e pegamos a parte inteira da divisão. Se essa divisão tiver resto, significa que precisamos ler um setor a mais para contemplar o restante dos dados. Nada de mais portanto. A função count_kernel_sectors ficou assim:

uint32_t count_kernel_sectors(std::vector<u_int8_t> &exec_bytes,
                              std::ostringstream &extended_string) {
  uint32_t os_size = exec_bytes.size() % SECTOR_SIZE != 0
                         ? uint32_t(exec_bytes.size() / SECTOR_SIZE) + 1
                         : uint32_t(exec_bytes.size() / SECTOR_SIZE);

  extended_string << "os_size: " << std::dec << os_size << " sectors"
                  << std::endl;
  return os_size;
}

Note que estamos retornando um uint32_t, que é um inteiro de 32 bits sem sinal. Precisamos escrever esse número a partir do byte 2 do booloader (os dois primeiros bytes são a instrução jmp load_kernel). A gente faz uma ginástica com os ponteiros, pego o segundo byte do vetor de bytes do bootloader, pego o endereço desse byte, faço um cast para falar que quero um ponteiro para um uint32_t nessa posição, e falo que o conteúdo desse endereço tem na verdade o valor os_size. A função record_kernel_sectors fica assim:

void record_kernel_sectors(uint32_t os_size,
                           std::vector<u_int8_t> &exec_bootloader_bytes) {
  (*(uint32_t *)&exec_bootloader_bytes[2]) = os_size;
}

A arquitetura é little endian, então o compilador já se encarrega de escrever os bytes menos significativos primeiro. Isso é o que nosso bootloader espera então está tudo certo.

Depois, é só escrever no arquivo de saída boringos.img, primeiro o vetor de bytes do bootloader, e depois o vetor de bytes do kernel. Esse trecho fica assim:

  std::ofstream kernelimage("./build/boringos.img");
  kernelimage.write(reinterpret_cast<char *>(&bootloader_bytearray[0]),
                    bootloader_bytearray.size());
  kernelimage.write(reinterpret_cast<char *>(&kernel_bytearray[0]),
                    kernel_bytearray.size());

Ufa, é isso. O código completo está no meu github. Se você rodar um make clean && make, e rodar o QEMU+gdb, o resultado será idêntico ao trabalho anterior. O que você pode fazer de diferente é ver o conteúdo da memória dos novos segmentos, em especial o .rdata e .data. Faça isso, obviamente, depois que o kernel já estiver carregado na memória (coloquei um break point em big_big_dummy_kernel com o comando hb *big_big_dummy_kernel):

Aparentemente, conseguimos ler o arquivo ELF do kernel certinho, o conteúdo das seções .rdata e .bss é esse mesmo apresentado na imagem acima, como era o nosso objetivo!

Com isso fechamos o P1, e vamos para o P2. Esse próximo trabalho espera que construamos um kernel não-preemptivo. Mas já vi aqui que o bootloader do P2 faz mais do que estamos fazendo no nosso código atual, ele entra em modo protegido e então o kernel já pode ser escrito em C/C++ com registradores de 32 bits. Mas tem bastante coisa pra fazer antes disso. O quanto, só botando a mão na massa pra saber…

Anterior

Próximo

No artigo anterior, movemos o bootloader para o endereço 0x80000 e carregamos um dummy kernel de apenas um setor (512 bytes) no endereço 0x1000. Neste artigo, vamos engordar esse dummy kernel para que ele tenha muitos setores, de forma que precisaremos carregar muitos setores do disco para o endereço 0x1000.

E como engordamos nosso kernel? Vou explicar o que fiz e depois explico os detalhes sórdidos. A primeira parte possui algumas pequenas alterações, mas no geral permanece da mesma forma: as funções print_char, print_string e o ponto de entrada kernel_entry.

[BITS 16]

%include "src/constants.asm"

global _start

_start:
    jmp kernel_entry

print_char:
    push bp
    mov bp, sp

    push ax
    push bx

    mov ax, [bp+4]
    mov ah, BIOS_INT_10H_OUTPUT
    mov bh, BIOS_INT_10H_PAGE_NUMBER_0
    mov bl, BIOS_INT_10H_FOREGROUND_COLOR_GM
    int BIOS_INT_10H

    pop bx
    pop ax

    pop bp

    ret

print_string:
    push bp
    mov bp, sp

    push ax
    push bx
    push si

    mov si, [bp+6]

    cld
loop_print_string:
    lodsb

    cmp al, NULL_CHARACTER
    je end_print_string

    push ax
    call print_char
    pop ax
    jmp loop_print_string

end_print_string:
    pop si
    pop bx
    pop ax

    pop bp

    retf

kernel_entry:
    mov ax, cs
    mov ds, ax
    mov es, ax

    mov ax, msg
    push ax
    call KERNEL_SEGMENT:print_string
    pop ax

    jmp 0x3000:big_dummy_kernel

msg db "Dummy Kernel Loaded!", CARRIER_RETURN, LINE_FEED, NULL_CHARACTER

Até aqui tudo bem? O código começa em _start e pula para kernel_entry. Ali ele corrige os registradores de segmento e invoca a função print_string (já explico alteração nessa chamada). Depois de corrigir a pilha, ele pula para outro endereço, bem longe do endereço 0x1000 onde esse código está rodando: ele passa o controle para 0x3000:big_dummy_kernel, que é depois do endereço absoluto 0x30000.

Vamos às explicações das alterações então. Primeiro, estamos chamando a função print_string de uma forma diferente. Onde antes era call print_string, agora fazemos call KERNEL_SEGMENT:print_string, conhecido como far call. Na primeira versão, o call chama o rótulo dentro de 16 bits de deslocamento dentro do mesmo segmento de código. Como pretendemos que o código que está depois de 0x30000 também chame essa função print_string, o código que está lá precisa apontar onde está o segmento de código da função print_string!

Há mais alguma alteração importante nessa chamada? Sim, afinal, quando a função print_string terminar sua execução, como ele vai saber o segmento original do código que chamou a função (no nosso exemplo, o código rodando após o endereço 0x30000)? Essa forma de chamar a instrução call (far call) empilha o registrador cs na pilha. Assim, ao retornar da função, recuperamos essa informação da pilha e restauramos o segmento de código de quem chamou a função. Isso por si só inclui duas alterações importantes que a função print_string precisa tratar:

1. Há agora um argumento adicional na pilha: o registrador cs. A forma de recuperar o argumento do parâmetro que será impresso na função é portanto deslocado em dois bytes

2. Ao retornar, precisamos alterar o registrador cs. Por sorte, há uma instrução que faz isso: retf. Já explico como ela funciona.

Antes de prosseguirmos, apresento como fica a pilha quando a função print_string é invocada junto com a execução das duas primeiras instruções (push bp e mov bp, sp).

Lembrem-se que a pilha cresce para baixo (conforme vamos adicionando elementos na pilha, o endereço do registrador sp diminui). A imagem mostra que apareceu um elemento adicional na pilha (no caso, o registrador cs). Quando anteriormente acessávamos o parâmetro msg com [bp+4], como cada parâmetro da pilha de 16 bits possui dois bytes, agora acessamos com [bp+6].

Outra alteração é que a instrução de retorno da função precisa corrigir essa pilha, e mais do que isso, saber para qual segmento de código a execução deve retornar. Por isso, usamos a forma far call: enquanto a função call normal desempilha o endereço de retorno (parâmetro ret na primeira imagem), o far call desempilha o endereço de retorno E o segmento de código de retorno (parâmetros ret e cs na segunda imagem).

Uma coisa que você pode indagar é: ué, se o código está em outro segmento, o parâmetro msg também não pode estar? E a resposta é sim, veremos que empilhamos um parâmetro que está no mesmo segmento do código. A diferença é que nesse caso, ao entrar nesses novos pontos de entrada do kernel (apresentaremos a seguir), os registradores ds e es são corrigidos para o mesmo segmento do código. Isso significa que a instrução far call armazena e altera o segmento de código, mas os outros permanecem inalterados. Como as instruções que buscam os dados da memória usam tais registradores implicitamente se nenhum segmento for explicitamente informado (como por exemplo, a função mov), acessamos os endereços corretos por tabela.

Temos outra implicação desse fato: a função print_char é invocada pela função print_string. As duas funções já estão no mesmo segmento de código, portanto a função print_string invoca a função print_char, usando a instrução call que já conhecemos, e por esse motivo o acesso ao parâmetro na pilha permanece [bp+4] e o retorno também permanece ret.

Agora que explicamos o funcionamento do código, vamos ver como ele fica depois da fronteira do endereço 0x30000.

...

msg db "Dummy Kernel Loaded!", CARRIER_RETURN, LINE_FEED, NULL_CHARACTER

TIMES 0x30000-($-$$) DB 0

big_dummy_kernel:
    mov ax, cs
    mov ds, ax
    mov es, ax

    mov ax, big_msg
    push ax
    call KERNEL_SEGMENT:print_string
    pop ax

    jmp 0x6000:big_big_dummy_kernel

big_msg db "Big Dummy Kernel Loaded!", CARRIER_RETURN, LINE_FEED, NULL_CHARACTER   

TIMES 0x60000-($-$$) DB 0

big_big_dummy_kernel:
    mov ax, cs
    mov ds, ax
    mov es, ax

    mov ax, big_big_msg
    push ax
    call KERNEL_SEGMENT:print_string
    pop ax

    jmp $

big_big_msg db "Big Big Dummy Kernel Loaded!", CARRIER_RETURN, LINE_FEED, NULL_CHARACTER

Perceba que agora que entendemos o funcionamento da função KERNEL_SEGMENT:print_string, pouco fizemos de diferente comparando com o caso da primeira invocação dessa função. Depois da string “Dummy Kernel Loaded!”, atochamos zeros para completar o código até o endereço 0x30000. Ai ajustamos os segmentos, empilhamos uma nova mensagem a ser apresentada ("Big Dummy Kernel Loaded!") e executamos a instrução far call para invocar a print_string. Depois do retorno da função, pulamos para um endereço mais longe ainda, o 0x60000. E o procedimento é repetido, mas para a mensagem "Big Big Dummy Kernel Loaded!".

Se tudo der certo, o que é esperado é a tela abaixo, que indica que estamos fazendo chamadas cross-segment e que nossa pilha está sendo corretamente manipulada.

Contudo, pequeno gafanhoto, em que momento esse monte de bytes desse Big Big Dummy Kernel foi carregado do disco para a memória? Pois é, eu ainda não mostrei esse código. Isso faz parte do crédito extra no P1.

Primeiro, vamos ver qual é o tamanho desse dummy kernel, para saber quantos setores eu preciso carregar do disco para a memória. Depois de compilado, o comando wc build/kernel mostra quantos bytes tem o arquivo.

Ok, então esse arquivo possui 393265 bytes. Como cada setor possui 512 bytes, então devemos ler 768,095703125 setores. Não conseguimos ler um setor de forma parcial, precisaremos ler esse setor inteiro. Então, ler 769 setores do disco é suficiente nesse caso e inclusive facilita nossa vida. A primeira alteração portanto é quantos setores do OS/Kernel serão lidos, e o arquivo bootloader.asm fica da seguinte forma:

os_size: ;in sectors
    dw 769, 0

Alterei o disk_index de db 0xff para db 11111111b. Perceba que 0xff é igual a 11111111b, então nada muda. Então, para que se importar com isso? O lance aqui é deixar explícito que todos os bytes dessa variável estão setados com 1 quando esse código é executado. É esperado que o bootloader altere essa variável na memória com o valor do registrador dl, e valores comuns são 0x0 (floppy), 0x80 (primeiro HD), 0x81 (segundo HD), etc. Assim, fica fácil acompanhar essa alteração no debugger e identificar se há algum erro nesse processo.

Agora começa a complicação. Se pudéssemos tratar o disco como um conjunto contíguo de bytes na memória, agrupados em blocos de 512 bytes (os famigerados setores), poderíamos pedir para ler depois de 512 bytes (esses primeiros pertencem ao bootloader) até onde gostaríamos, nesse caso, 769 setores após o primeiro setor. Para dispositivos mais novos, isso já existe e se chama LBA. O esquema LBA permite endereçar blocos no disco, começando do bloco 0 linearmente até o fim do disco. BIOS mais novas possuem extensões da INT 13h que permitem ler discos usando esse esquema. Contudo, controladoras de disco mais antigas e BIOS mais antigas não possuem esse luxo. Nesse caso vamos com o bom (bom pra quem?) e velho (bota velho nisso) esquema CHS.

Nós sabemos exatamente quais blocos queremos ler. Nesse artigo queremos ler do segundo setor (endereço LBA 1) até o fim do arquivo kernel (endereço LBA 769). Precisamos transformar esses endereços no padrão de cilindros, cabeças, trilha e setores.

Para quem programou em C/C++, provavelmente você já encarou o problema de acessar um byte arbitrário em uma matriz 3D alocada de forma contígua. Você pode encarar uma matriz 3D como várias matrizes 2D dispostas uma ao lado da outra. Há várias formas de se encarar esse problema, e várias soluções possíveis. Para mais informações, veja aqui.

Para encontrar um bloco arbitrário na estrutura da imagem acima, precisamos identificar em qual setor, em qual trilha, em qual cabeça e em qual cilindro está o nosso dado. Precisamos de algumas informações adicionais para isso:

• Quantos setores por trilha esse disco possui?

• Quantas cabeças esse disco possui?

Com essas informações já conseguimos fazer um cálculo LBA para CHS. Definimos portanto mais três variáveis:

sectors_per_track:
    db 0

number_of_heads:
    db 0

current_lba_address: ; second sector
    dw 1 

Começamos do segundo setor (LBA 1) com a variável current_lba_address. As outras duas variáveis dizem respeito às perguntas feitas anteriormente e já verificamos como conseguimos tais dados.

Antes, fixamos os_size como 1 e solicitamos a interrupção BIOS 13h que lesse apenas um setor, no endereço CHS 0,0,2 (pois diferente do LBA, os setores são indexados a partir de 1). Agora temos um número bem maior em os_size.

Primeiro de tudo, nós resetamos o sistema do disco:

    ; let's reset the disk system first
reset_disk:
    mov dl, [disk_index]
    mov ah, BIOS_INT_13H_RESET_DISK_SYSTEM
    jc reset_disk ; reset went wrong. Try again

Isso serve pois não sabemos em que estado está o hardware do disco, precisamos que ele esteja pronto para receber nossas requisições de leitura. Inclusive, se a leitura for mal sucedida (Carrier Flag esteja setada), saltamos para tentar fazer o reset novamente.

Depois disso, vamos obter a geometria do disco, ou seja, responder às perguntas feitas anteriormente:

    ; let's get disk geometry
    mov ah, BIOS_INT_13H_GET_DISK_GEOMETRY
    push es
    xor di, di
    mov es, di ; hack to get es:di = 0x0000:0x0000
    int BIOS_INT_13H
    pop es

O comando em si é apenas o mov ah, BIOS_INT_13H_GET_DISK_GEOMETRY e int BIOS_INT_13H. O restante do código está presente pois algumas BIOS possuem um bug e se os registradores es:di não possuirem os valores 0x0000:0x0000 essa query retorna valores inválidos. Então estou apenas salvando o valor antigo de es e zerando ele junto com o registrador di.

A essa interrupção retorna o índice da última cabeça no registrador dh (iniciando de zero), portanto, ao adicionar 1 nesse valor temos o número total de cabeças do disco. O registrador cl retorna o número total de setores por trilha (começando em um). Contudo, apenas os 6 bits menos significativos desse registrador representam o número de setores por trilha, portanto temos valores válidos entre 1 a 63. Os outros dois bits são os dois bits mais significativos do índice do último cilindro do disco, que em compõem esse valor em conjunto com os outros 8 bits do registrador ch. Por sorte, nosso dummy kernel não é tão grande assim para termos que fazer qualquer tipo de checagem de fronteiras no número de cilindros, a ponto de não precisarmos nem armazenar esse valor. Temos apenas que garantir que vamos obter apenas os últimos 6 bits do registrador cl, e podemos fazer isso com a máscara BIOS_INT_13H_SECTOR_MASK (valor 00111111b) e a instrução and. Dessa forma, os últimos bits do registrador cl são descartados e como não vamos usá-los agora, isso é exatamente o que precisamos para o momento. Esse trecho fica portanto assim:

    mov [number_of_heads], dh
    inc byte [number_of_heads]

    and cl, BIOS_INT_13H_SECTOR_MASK
    mov [sectors_per_track], cl

Agora, já sabemos quantos setores por trilha esse disco tem, e quantas cabeças também.

O destino da cópia você já conhece, vamos copiar os setores para o endereço es:bx, portanto:

    ; we'll copy sectors to here
    mov bx, KERNEL_SEGMENT
    mov es, bx

Agora vem a parte mais difícil: indicar para a interrupção a partir de qual setor devemos ler. Para exemplificar, vamos usar exemplos números e figuras. Suponha que você deseje ler endereço LBA 105 do disco. Esse disco possui uma geometria com 36 setores por trilha e duas cabeças (ou seja, é um floppy disc). Teríamos algo do tipo:

Relembrando um pouquinho das aulas de Matemática Discreta e Álgebra, para o setor LBA 105, com 36 setores por trilha, precisamos de 2*36 + 33 setores. Com a operação de módulo (resto da divisão), 105 mod 36 é igual a 33. Contudo, os setores iniciam em 1, então precisamos somar 1 para que a chamada da interrupção BIOS 13h ocorra de forma correta.

Pegando a parte inteira dessa divisão, nós obtemos o número da trilha (105 dividido por 36 dá 2 e uns quebrados). Isso bate com nossa figura, track 2. Mas com duas cabeças, temos os índices de cabeça variando de 0 a 1. Portanto, precisamos pegar o número da trilha e também usar a operação módulo. Assim, 2 (número da trilha) mod 2 (número de cabeças do disco) é igual a zero, então nossa cabeça é 0 (head 0 na figura). Para encontrar o cilindro, basta pegar a parte inteira da divisão do número da trilha com o número de cabeças do disco: 2 div 2 é igual a 1, portanto, cilindro 1, conforme nossa figura apresenta. Assim, o endereço LBA 105 é igual ao endereço CHS (1,0,34) para esta geometria de disco de 36 setores por trilha e 2 cabeças. Se quiser olhar mais a esse respeito, veja aqui.

Vamos ver como fica nosso código:

read_sector:
    ; which Logical Block Address do we have to copy now? 
    mov ax, [current_lba_address]

    ; have we reached the end?
    cmp ax, word [os_size]
    jg end_read_sector

    ; not yet, lets get CHS parameters
    mov bl, [sectors_per_track]
    div bl
    inc ah
    mov cl, ah ; here, we know which sector we start
    xor ah, ah ; al has the track number. 

    div byte [number_of_heads]
    mov dh, ah ; now we get the head number...
    mov ch, al ; ... and the cylinder number. We have all we need.

Começamos verificando qual endereço LBA vamos converter (começa em 1, representando o setor 2 no disco, que é o primeiro setor logo após o bootloader). Depois verificamos se já chegamos ao fim da leitura, ou seja current_lba_address é igual ao os_size, e current_lba_address é incrementado a cada leitura. Em caso negativo, ainda há leitura de setores a ser feita.

Então, ax possui o endereço LBA. Ao colocar sectors_per_track e executar a instrução div bl, o resto da operação fica no registrador ah e o quociente em al. Significa que ah (depois de incrementado em 1) possui o índice do setor, e al possui o número da trilha.

Devemos agora usar o número de trilha para encontrar os índices de cabeça e cilindro. Esse valor deve estar em ax; al já contém essa informação, mas ah está com o valor sujo e precisamos zerá-lo. Por isso, a instrução xor ah, ah.

Neste ponto, ax já tem o número de trilha. Dividindo esse valor pelo número de cabeças do disco (variável number_of_heads), temos ah com o índice da cabeça e al com o índice do cilindro.

Ufa, já temos todos os valores nos registradores exigidos pela interrupção de leitura BIOS 13H. Ou quase todos.

Ainda falta nos livrarmos de um grande elefante branco no meio da sala: quantos setores devemos ler de uma vez? Até o momento, estávamos lendo apenas um setor do disco. Um algoritmo ingênuo diria nos instruiria a ler a maior quantidade de setores possíveis de uma vez. O problema é que há restrições impostas pelas arquiteturas e controladoras de disco. Vamos discutir algumas delas.

A primeira limitação é a quantidade máxima teórica que podemos ler usando a interrupção BIOS 13H. A quantidade de setores que gostaríamos de ler em uma chamada da interrupção fica armazenada no registrador al. Valores possíveis então poderiam ser de 1 a 255, mas aqui diz que é até 128. Ainda assim, parece não ser possível ler tudo isso de uma vez em um floppy disk, e aqui é dito que em controladoras antigas, pode ser possível ler apenas 18 setores de uma vez, e quando usando o emulador BOCHS, o máximo permitido é 72.

Ainda há outro problemão: o endereço es:bx não pode cruzar a fronteira de 64KB de um segmento físico na memória durante a leitura. No nosso caso, começamos no endereço 0x1000 (4096 bytes) e vamos até o endereço 0xfa00 (64 KB). Nesse intervalo, temos 59.904 bytes, e com setores com tamanho de 512 bytes cada, temos um total de 117 setores a serem lidos nesse intervalo.

Pegando um mínimo denominador comum, você pode ir lendo de 18 setores 6 vezes, e no fim leria apenas 9 setores para parar na barreira do segmento físico. Ou se for ler 16 setores de uma vez, você teria que fazer 7 leituras completas e mais uma com 5 setores e parar na barreira do segmento. Ao cruzar a barreira do segmento físico, você tem mais 64KB para o próximo segmento. Setores de 512 bytes totalizam 125 setores, um bom número seria um número de cinco, mas menor que 18? Sinceramente, não vale a pena. Enquanto não precisamos otimizar o código, podemos ler setor por setor que não teremos problema nenhum. Portanto, defini BIOS_INT_13H_SECTOR_COUNT = 1.

Invocamos a função como de costume (lembre-se que o registrador es já havia sido corretamente definido):

    mov dl, [disk_index] 
    mov al, BIOS_INT_13H_SECTOR_COUNT ; how many sectors are we reading at once?
    mov ah, BIOS_INT_13H_READ
    mov bx, KERNEL_INIT ; bx will be always the same. es is the register that will change     
    int BIOS_INT_13H

    jc read_sector ; if CF is set, an error occurred. Try again

Fazemos a leitura, e checamos se a Carrier Flag está definida. Em caso positivo, houve um erro na leitura, pule para read_sector e repita o processo.

Em caso negativo, a leitura foi bem sucedida. Malandramente, eu mantenho o registrador bx fixo, calculo quantos bytes foram lidos e incremento apenas o registrador de segmento es. Por exemplo, se apenas um setor foi lido como é o nosso caso (BIOS_INT_13H_SECTOR_COUNT = 1), significa que lemos 0x200 bytes (512 em decimal), basta fazer um shift right no número hexadecimal 0x200 para resultar em 0x20. Em decimal, basta fazer (SECTOR_SIZE*BIOS_INT_13H_SECTOR_COUNT)/16 (é o valor definido na constante BIOS_INT_13H_SEGMENT_OFFSET no arquivo constants.asm).

Depois, incrementamos o endereço LBA com o número de setores lidos, e fazemos um salto para ler mais setores. Quando todos os setores forem lidos, o kernel está com certeza no endereço 0x0000:0x1000, basta pular para lá e executar o que já mostramos no começo desse artigo. O trecho final do código fica assim:

    mov ax, es
    add ax, BIOS_INT_13H_SEGMENT_OFFSET
    mov es, ax ; we've read BIOS_INT_13H_SECTOR_COUNT*SECTOR_SIZE bytes. Move es to new position (move to segment BIOS_INT_13H_SEGMENT_OFFSET)

    add word [current_lba_address], BIOS_INT_13H_SECTOR_COUNT ; move LBA pointer

    jmp read_sector

end_read_sector:
    ; the kernel is entirely in the memory. Jump to its start address
    jmp KERNEL_SEGMENT:KERNEL_INIT

O código completo está no meu github na branch p1-v5. No próximo artigo vamos parar de roubar, nosso Makefile está fazendo com que o linker gere arquivos raw binary, mas o Projeto P1 espera que esses arquivos sejam gerados no formato ELF, e precisamos criar um programa que faça o parser nesses arquivos e os junte, inclusive alterando o campo campo os_size no arquivo bootloader.asm a depender do tamanho do código presente no kernel. Essa será a nossa próxima missão, até lá.

Anterior

Próximo

No artigo anterior nós mostramos o layout da imagem do SO e também o layout de memória. Nesse artigo, vamos proceder com a leitura dos dados na imagem para a posição correta do kernel na memória (0x1000).

Contudo, ainda não temos um kernel, então vamos trabalhar com o Dummy Kernel. No fim das contas por enquanto queremos apenas carregar o Kernel na posição 0x1000, e já cuidamos para que, se ele for muito grande, este não sobrescreverá o bootloader, que foi movido da posição 0x7c00 para 0x80000.

Para este teste, criei um arquivo kernel.asm e movi o código de impressão de caracteres e strings para ele. Vamos ver o que foi necessário para que isso funcione.

No arquivo booloader.asm, entre os rótulos _start e load_kernel, adicionamos os seguintes dados:

os_size:
    dw 1, 0

disk_index: 
    db 0xff

O primeiro campo, os_size, possui duas palavras e indica o tamanho do Sistema Operacional que deve ser lido do disco, em número de setores. Ao juntar o bootloader e o kernel em artigos posteriores, o utilitário irá alterar esse campo para indicar o tamanho do kernel que deve ser posteriormente lido. No momento, temos um kernel dummy e, neste nosso artigo, sei que tem menos de 512 bytes, portanto, ler um setor é suficiente.

Note ainda que o defini o 1 na primeira palavra. Não deveria ser na segunda? Não, pois o utilitário que junta o bootloader e kernel possui 32bit, e 32bit na arquitetura x86 é LITTLE ENDIAN. Significa que, do ponto de vista dessa aplicação, ela irá escrever os 32bit de uma vez como um número só, e os bits menos significativos ficam nos menores bytes na memória, e portanto, aparecem antes.

Note ainda que se um número de 32bit for escrito nessa região, teremos que nos desdobrar para fazer “caber” nos registradores de 16bit. Possivelmente a solução é quebrar esse número grande e fazer várias leituras. Mais do que isso, se pretendemos usar a interrupção BIOS 13h para fazer a leitura e não pudermos ler tudo de uma vez, precisamos saber como ir avançando a leitura usando o padrão CHS (Cylinder, Head and Sector). Essa conversão será um problema para o nosso eu do futuro.

O próximo campo, disk_index, guardará qual disco deve ser lido. O disco de boot pode estar em qualquer um dos dispositivos: Floppy, HD, SSD, CD-Rom, Rede… De onde devemos ler? Por sorte, ao achar o setor de boot, quando o controle é passado ao bootloader, o registrador dl possui o índice do disco que devemos usar, e podemos passar esse valor diretamente para a interrupção BIOS 13h. Como podemos perder esse valor se o registrador dx for usado, salvamos esse valor para uso futuro. Você pode me perguntar, o que o valor 0xff significa? Na realidade, nada. Foi um valor arbitrário que defini, pois como estamos usando o primeiro floppy disk no QEMU, esse valor deve ser 0. Assim, eu garanto que essa posição de memória foi corretamente alterada de 0xff para 0 e isso facilita nossa depuração.

Aproveitei a oportunidade para deixar o registrador bp em um endereço bem definido:

    mov sp, STACK_POINTER_BOOTLOADER
    mov bp, sp

Isso acompanha aquela ideia do registro de ativação já explicada anteriormente. Apesar de nossas funções ajustar tais registradores, não dói fazer isso agora.

Depois, antes de copiar o bootloader para a posição 0x80000, salvamos o disco presente no registrador dl, como dito anteriormente:

    mov [ds:disk_index], dl

Após já estar executando na posição nova, fazemos a leitura do kernel:

new_boot_region:
    mov ax, NEW_BOOTLOADER_SEGMENT
    mov ds, ax

    mov ah, BIOS_INT_13H_READ
    mov al, [ds:os_size]
    mov ch, BIOS_INT_13H_CYLINDER_NUMBER
    mov dh, BIOS_INT_13H_HEAD_NUMBER    
    mov cl, BIOS_INT_13H_SECTOR_NUMBER
    mov dl, [ds:disk_index]
    mov bx, KERNEL_SEGMENT
    mov es, bx
    mov bx, KERNEL_INIT
    int BIOS_INT_13H

    jmp KERNEL_SEGMENT:KERNEL_INIT

Agora é necessário ler o disco para buscar o kernel e posicioná-lo no endereço 0x1000. Vamos ver o que é necessário para invocar a interrupção BIOS 13h. Dentre todas as funções que podemos fazer com essa interrupção (estamos falando de manipulação de discos, então podemos ler, escrever, formatar, resetar, etc), nosso interesse é ler do disco, portanto, o valor correto é o BIOS_INT_13H_READ = 0x2. Depois, indico quantos setores eu pretendo ler de uma vez. Se você voltar, notará que eu defini de antemão o valor para 1 (1 setor - 512 bytes), pois já sei que agora meu kernel tem menos de 512 bytes1.

Já sabemos quantos setores queremos ler, mas começamos a leitura a partir de onde no disco? O problema é mais ou menos parecido com encontrar uma determinada faixa musical em um LP tocando em uma vitrola2.

No caso da interrupção da BIOS 13h, precisamos indicar em qual Cilindro (Cylinder), Cabeça (Head) e Setor (Sector) vamos iniciar a leitura. Se tiver dúvidas em qual a lógica por trás disso, veja esse vídeo aqui. No nosso caso, o primeiro setor de todos é nosso bootloader, que fica no Cilindro 0, Cabeça 0 e Setor 1 (note que o setor não começa no 0). Nosso kernel está grudado e está logo na sequência, portanto queremos começar a leitura a partir do Cilindro 0, Cabeça 0 e Setor 2. Atente-se novamente, se você precisar ler uma quantia muito grande de setores, provavelmente precisará quebrar uma leitura grande em várias pequenas, recalculando os índices de Cilindro, Cabeça e Setor no processo.

Mas a vida, além de não ser fácil, ainda é difícil. Isso porque os valores de cilindro, cabeça e setor são guardados nos registradores ch, dh e cl, respectivamente. E enquanto não temos problemas com relação aos 8 bit que podem representar as cabeças, de 0 a 255, o mesmo não pode ser dito dos cilindros e setores. Isso porque, na verdade o índice de cilindro é um número de 10 bits, e o número de setores é um número de 6 bits. Significa que pegamos emprestado dois bits dos setores para compor os cilindros. É confuso, mas acredito que a imagem abaixo possa ajudar no entendimento.

Sem surpresa então, temos as constantes BIOS_INT_13H_CYLINDER_NUMBER = 0, BIOS_INT_13H_HEAD_NUMBER = 0 e BIOS_INT_13H_SECTOR_NUMBER = 2, e não precisamos de nenhum malabarismo para encaixar os bits do cilindro e setor. BIOS_INT_13H_SECTOR_NUMBER = 2 usa menos que os 6 bits disponíveis, BIOS_INT_13H_SECTOR_NUMBER = 2 em binário é 00000010, então os dois últimos bits já estão zerados, e para o cilindro, é só deixar ch = 0.

Prosseguindo pelo código, recuperamos o disco que devemos ler e guardamos esse valor no registrador dl, que será usado diretamente pela interrupção.

Por fim, só falta indicar onde deveremos guardar os dados lidos. Lembre-se que queremos colocar o kernel em 0x1000, então ES:BX valendo 0x0000:0x1000 é suficiente para o nosso caso (representado pelas constantes KERNEL_SEGMENT:KERNEL_INIT).

Assim que a interrupção finaliza, saltamos para o endereço 0x0000:0x1000 usando a instrução jmp KERNEL_SEGMENT:KERNEL_INIT, pousando no endereço absoluto 0x1000, como o esperado.

Esse endereço possui o código presente no arquivo kernel.asm, que é basicamente as funções print_char e print_s retiradas do arquivo bootloader.asm. A diferença foi que ajustei os registradores ds e es para o mesmo segmento de cs (zero, portanto), e alterei a mensagem a ser impressa para “Dummy Kernel Loaded!”. Nada mais é alterado em relação ao que já existia anteriormente.

Como agora temos um bootloader e um kernel (cof cof), não faz mais sentido carregar a imagem como bootloader, por isso gerei um novo arquivo chamado boringos.img, que é uma amálgama dos dois anteriores. Na real são apenas os bytes copiados em sequência usando cat.

O novo Makefile ficou então:

SRCDIR=src
OUTPUTDIR=build

all: kernel bootloader
	cat $(OUTPUTDIR)/bootloader $(OUTPUTDIR)/kernel > $(OUTPUTDIR)/boringos.img

%.o: $(SRCDIR)/%.asm
	nasm -wall -O2 -f elf32 -F dwarf -g -o $(OUTPUTDIR)/$@ $<

bootloader: bootloader.o
	ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x0 -s --oformat binary -o $(OUTPUTDIR)/$@ $(OUTPUTDIR)/$<

kernel: kernel.o
	ld -nostdlib -O2 -g -m elf_i386 -Ttext 0x1000 -s --oformat binary -o $(OUTPUTDIR)/$@ $(OUTPUTDIR)/$<

clean:
	rm -rf $(OUTPUTDIR)/*

Perceba que deixei a compilação dos arquivos .asm de forma genérica. O mesmo não pode ser dito dos executáveis bootloader e kernel, já que estes são posicionados em seções de texto diferentes (parâmetros -Ttext 0x0 e -Ttext 0x1000).

O arquivo VM_BoringOS.sh foi alterado para usar o novo arquivo boringos.img. Já no arquivo debug_BoringOS.sh adicionamos os símbolos do arquivo kernel.o no endereço 0x1000. Retirei os símbolos do bootloader do endereço 0x7c00, e deixei apenas no endereço 0x80000, para evitar conflitos do mesmo símbolo estar em lugares diferentes. Alterei o primeiro breakpoint de hbreak *_start para hbreak *0x7c00, já que não temos mais o símbolo _start carregado pelo gdb no endereço 0x7c00…

Se tudo der certo, ao iniciar a depuração e solicitar ao depurador que continue a execução, você deve ver a tela abaixo.

OBS: Fique esperto com os segmentos. Inicialmente eu tentei fazer com que KERNEL_SEGMENT:KERNEL_INIT fosse 0x0100:0x0000. Embora isso seja igual a 0x1000:0x0000, que é igual ao endereço absoluto 0x1000, isso fez com que eu tivesse dor de cabeça com os helpers do gdb. Nesse caso, o helper do gdb para o modo real vai fazer SIGTRAPs dependendo de onde você coloca o breakpoint, e a execução não vai para frente com os comandos s, si, n, stepo, etc no gdb. Observe esse exemplo:

Logo após o gdb parar a execução no endereço 0x7c00, eu pedi um novo breakpoint em 0x1000. Ele informa que o programa parou por algum breakpoint definido, mas não por mim. Para prosseguir, tive que fazer um delete e apagar todos os breakpoints presentes. Assim, o si volta a funcionar e você pode setar os breakpoints novamente.

Ajustando os segmentos dos registradores cs, ds e es para 0x0000, o problema parou de acontecer.

O código para essa versão estão aqui.

Anterior

Próximo

Continuando a especificação do Projeto 1 (veja o post anterior aqui!), em breve estaremos lendo carregando o kernel para a memória (e ele ainda nem existe no nosso código). Contudo, temos um problema: nos é pedido que o kernel seja carregado no endereço 0x1000. Se o kernel ultrapassar 27KB, ele vai alcançar a região de memória 0x7c00, que foi onde a BIOS colocou o nosso bootloader. Se a BIOS ainda não tiver terminado seu trabalho (e ainda há muito o que fazer antes de passar o controle ao kernel), o código do Kernel sobrescreverá o bootloader, e coisas ruins podem acontecer.

Temos duas informações importantes:

1. Your bootloader can safely modify memory in the range [0x0a00, 0xa0000) without having to worry about overwriting video memory, the interrupt vector table, or BIOS.

2. Notice that a loaded larger kernel may overlap with the bootloader, so you will have to relocate the bootloader to a higher address that can't be overwritten before loading the kernel (see extra credit).

Portanto, se a gente mover o bootloader para um endereço alto, próximo da fronteira 0xa0000, não deveremos ter problemas. E como esse não é um sistema de produção, decidi mover o bootloader para o endereço 0x80000. Assim, o kernel tem espaço de sobra para ocupar entre os endereços 0x1000 e 0x80000.

Minha ideia é portanto fazer como a imagem abaixo.

Os passos que descrevem a imagem acima são:

1. Nossa imagem é um bloco contíguo concatenado do bootloader (512 bytes) e o kernel, que ainda não sabemos o tamanho. Se o bootloader exceder os 512 bytes, é necessário considerar isso ao ler o disco e mover o bootloader. Mas não cuidaremos disso até que seja necessário. Portanto, assumimos que nosso bootloader tem 512 bytes.

2. A BIOS se encarrega de colocar nosso bootloader no endereço 0x7c00 (1 - BIOS LOADING, na imagem acima). Já tratamos desse procedimento em artigos anteriores.

3. O bootloader corrige os segmentos, e ajusta a pilha para o endereço 0x9ffff.

4. O bootloader então copia o conteúdo de 512 bytes do endereço 0x7c00 para o endereço 0x80000 (2 - BOOTLOADER MOVING). Isso significa que há uma cópia do bootloader nesse novo endereço.

5. Fazemos um far jump para a próxima instrução no segmento 0x8000. Isso implica que estamos continuando o código de nosso bootloader, mas em outro ponto da memória!

6. A partir dai, o bootloader pode fazer o que for necessário, por exemplo, ler o kernel do disco e posicioná-lo em 0x1000, sem se preocupar com sobreposições. Não temos isso pronto ainda, e vamos continuar usando nossas funções print_char e print_string para testes.

O que temos de novo no nosso código? Vamos descobrir!

Criei mais três constantes. NEW_BOOTLOADER_SEGMENT guarda o segmento da nova posição do bootloader, 0x8000. Se considerarmos que o segmento do bootloader velho é 0x07c0, então podemos usar o mesmo deslocamento para os dois, partindo de BOOTLOADER_INIT, 0x0000. Isso resulta nos endereços absolutos 0x7c00 e 0x80000 para o velho e novo bootloader, respectivamente. Por fim, defini a constante de quantos bytes eu quero mover, e como nosso bootloader tem o tamanho de 1 setor do disco, definimos a constante SECTOR_SIZE = 512.

Como podemos copiar os bytes do bootloader de 0x7c00 para 0x80000 de forma eficiente? Podemos utilizar a instrução rep movsb. Essa instrução copia a quantidade de bytes que está no registrador CX do endereço DS:SI para o endereço ES:DI. Para isso ele incrementa automaticamente os registradores SI e DI a cada byte copiado (caso a Flag DF - Direction Flag tenha o valor 0), ou decrementa (caso a Flag DF - Direction Flag tenha o valor 1). Podemos alterar o valor dessa flag com as instruções CLD - Clear Direction Flag e STD - Set Direction Flag). Como você deve ter notado, precisamos do valor 0 nessa flag, então a instrução que devemos usar é CLD.

Então agora ficou fácil. Precisamos definir os valores dos registradores DS (segmento de origem - 0x07c0), ES (segmento de destino - 0x8000), endereços de origem e destino nos segmentos, respectivamente, SI e DI (começaremos do 0), CX indica quantos bytes serão copiados (512), e zeramos o direction flag (CLD). E ai podemos executar a instrução rep movsb. Essa parte do código ficou assim:

load_kernel:
    mov ax, STACK_SEG_BOOTLOADER
    mov ss, ax
    mov sp, STACK_POINTER_BOOTLOADER      

    mov ax, SEGMENTS_BOOTLOADER
    mov ds, ax
    mov ax, NEW_BOOTLOADER_SEGMENT
    mov es, ax

    mov si, BOOTLOADER_INIT
    mov di, BOOTLOADER_INIT

    mov cx, SECTOR_SIZE

    cld
    rep movsb
before_jump:
    jmp word NEW_BOOTLOADER_SEGMENT:new_boot_region
    
new_boot_region:
    mov ax, NEW_BOOTLOADER_SEGMENT
    mov ds, ax

Depois que a cópia terminou, podemos “pular” para o novo segmento para o rótulo new_boot_region, ou seja, justamente a próxima instrução. A pilha já está no endereço certo (SS = 0x9000), os registradores CS e ES já apontam para o novo segmento 0x8000 (CS foi atualizado na instrução jmp). Portanto, o único registrador de segmento errado ainda é o DS, e é isso que corrigimos logo após o jmp ser efetuado no código acima.

Dai pra frente, o código é o mesmo do artigo anterior. Deve aparecer na tela a mensagem “pHello, world”. Se você executar esse código, tudo funcionará conforme imaginado.

Duas observações para esse novo código:

Primeiro, a instrução lodsb, usada na função print_string, também usa o Direction Flag para fazer a cópia dos bytes. Quem sabe faz ao vivo! No nosso caso, estava funcionando sem querer, mas para garantir que funcionará *sempre*, precisamos executar a instrução cld antes da primeira execução da instrução lodsb. Isso foi corrigido nessa versão.

Segundo, depois da cópia do bootloader, os endereços 0x7c00 e 0x80000 possuem o mesmo código certo? Portanto, para facilitar a depuração com o gdb, é útil adicionarmos os símbolos no novo endereço também no arquivo debug_BoringOS.sh:

-ex "add-symbol-file $CURRDIR/build/bootloader.o 0x80000"

Contudo, fazer breakpoints usando os símbolos agora não funciona mais, pelo menos não da forma como se é esperado. Afinal, temos os mesmos símbolos em dois endereços diferentes. Se eu fizer um hbreak *before_jump, onde ele colocará o breakpoint? Na minha execução aqui, ele colocou aqui:

Hum… ele colocou no endereço do novo bootloader (0x8004f). Acredito que ele sobrescreveu o endereço do símbolo before_jump quando o segundo add-symbol-file foi executado. E o engraçado é que se eu pedir para continuar a execução agora, esse breakpoint nunca será executado, já que ele está antes do jmp no segmento 0x8000, mas o jmp pula para o rótulo new_boot_region, que fica depois. Enfim, isso não é nenhum problema, e é o comportamento esperado.

Para evitar essa situação, se precisar pular para algum símbolo do arquivo bootloader.o, o melhor a ser feito é carregar os símbolos em apenas um dos dois endereços. Ou então use breakpoints com endereços absolutos. Se não precisar de breakpoints com símbolos, carregar o mesmo símbolo nos dois endereços é uma boa ideia na visualização da execução no gdb.

Anterior

Próximo

Se você ainda não conferiu o post anterior, corre lá para preparar o projeto. Sigamos.

Eu estava meio destreinado em assembly, e uma das etapas do Projeto 1 é fazer o Design Review. Nele é pedido para fazermos as funções print_char e print_string em assembly. Ótima oportunidade! Estávamos escrevendo um caractere na tela no post anterior, mas convenhamos, aquilo não é exatamente uma função certo? Um dos pré-requisitos de uma função é ser chamada com a instrução CALL, portanto, mudanças seriam necessárias.

Havia outras coisas que eu propositalmente deixei incompleto, no post anterior eu não mexia na pilha nem nos registradores de segmento. Mas se agora vamos definir funções formalmente, então é hora também de ajustarmos tais valores.

Ao começar a mexer no código, tive muito problema pois o código carregado pelos símbolos do arquivo bootloader.o não correspondiam às instruções que o gdb me mostrava. Isso é o equivalente a traduzir um texto escrito em alemão com um dicionário japonês. Sem conseguir resolver isso, eu não conseguiria avançar muito.

O problema principal é que esse código inicial é um código 16-bit em modo real, mas o NASM está gerando código ELF32. Até ai tudo bem, já que minhas instruções não usam registradores de 32bit ainda. O linker também está gerando código elf_i386, e enquanto o otimizador não fizer nenhuma gracinha, até aqui estamos bem.

O problema começa quando esse código é carregado no QEMU e atachado ao GDB. Estava usando o qemu-system-x86_64, e isso por si só não é um problema devido a retro compatibilidade da arquitetura x86_64, mas o GDB alterava a instrução que me era apresentada. Havia ocasiões em que registradores de 32bit me eram apresentados quando rodava o layout asm no GDB (do nada aparecia um eax), e eu levei muito tempo para entender o que estava acontecendo.

Primeiro, por enquanto pelo menos, eu alterei o qemu-system-x86_64 para qemu-system-i386. Isso não é suficiente. Segundo, preciso indicar para o NASM gerar código de 16bit. Isso é feito com a diretiva [BITS 16] no código bootloader.asm.

Segundo, a visualização padrão do GDB é muito ruim. Ou pelo menos eu achei algo BEM melhor aqui! Dessa forma conseguimos altera a visualização do GDB para que ele mostra uma espécie de visualização Real Mode 16bit, exatamente o que nós queremos!

Vamos ver as mudanças então.

Makefile

Criei uma pasta src, e movi o código fonte para lá (por enquanto o arquivo bootloader.asm). Também criei uma pasta de build, onde os arquivos objetos e executáveis são colocados. O Makefile foi adaptado para usar essas duas novas pastas.

Pasta gdb_util e arquivo debug_BoringOS.sh

Os arquivos helper para alterar a visualização do GDB, obtidos aqui, foram incluídos na pasta gdb_util. O comando que invoca o gdb foi alterado para contemplar tais arquivos:

gdb -ix "$CURRDIR/gdb_util/gdb_init_real_mode.txt" -ex "set tdesc filename $CURRDIR/gdb_util/target.xml" -ex 'target remote localhost:1234' -ex 'set confirm off' -ex "add-symbol-file $CURRDIR/build/bootloader.o 0x7c00" -ex 'set confirm on' -ex 'hbreak *_start' -ex 'c'

Observe o antes e depois de usar esses helpers. Antes:

Depois:

A diferença é brutal, eu consigo acompanhar muito melhor o conteúdo dos registradores e algumas partes da memória.

print_char e print_string

Indo ao ponto que importa, organizei melhor o código assembly. Defini algumas constantes e as coloquei no arquivo constants.asm. O conteúdo desse arquivo está assim:

%define STACK_SEG_BOOTLOADER 0x9000
%define STACK_POINTER_BOOTLOADER 0xffff
%define SEGMENTS_BOOTLOADER 0x7c0

%define BIOS_INT_10H 0x10
%define BIOS_INT_10H_OUTPUT 0x0e
%define BIOS_INT_10H_PAGE_NUMBER_0 0x00
%define BIOS_INT_10H_FOREGROUND_COLOR_GM 0x02

%define NULL_CHARACTER 0

%define LINE_FEED 10
%define CARRIER_RETURN 13

%define BOOT_SIGNATURE db 0x55, 0xaa

Vamos explicar alguns dos valores, mesmo que de forma superficial agora. Primeiro, as duas primeiras constantes dizem respeito à pilha. Segundo o trabalho: “Your bootloader can safely modify memory in the range [0x0a00, 0xa0000) without having to worry about overwriting video memory, the interrupt vector table, or BIOS.” Então, eu joguei a pilha para o endereço 0x9ffff (STACK_SEG_BOOTLOADER:STACK_POINTER_BOOTLOADER), um byte a menos que o valor limite 0xa0000. Como a pilha decresce, temos um bom espaço sem problemas, inclusive quando realocarmos o bootloader em um endereço mais alto.

Estamos ajustando os registradores de segmento também, com a constante SEGMENTS_BOOTLOADER, em especial os registradores ds e es. Isso porque a função print_string usa a instrução lodsb, que utiliza esses registradores implicitamente. Como os valores buscados estão no mesmo segmento do código que inicia em 0x7c00, nada mais justo que ajustar tais registradores para esses valores também.

As constantes para a chamada de escrita de caractere no vídeo dispensam comentários. Em caso de dúvida, sugiro verificar aqui ou aqui.

Depois, há algumas definições para manipulação de string (NULL_CHARACTER, LINE_FEED e CARRIER_RETURN), e quem já trabalhou com strings em C ou similar sabem do que se trata. Na dúvida, consulte alguma Tabela ASCII.

Por fim eu defini a constante da assinatura do boot.

O código bootloader.asm, já incluindo as constantes, ficou assim:

[BITS 16]

%include "src/constants.asm"

global _start

_start:
    jmp load_kernel

print_char:
    push bp
    mov bp, sp

    push ax
    push bx

    mov ax, [bp+4]
    mov ah, BIOS_INT_10H_OUTPUT
    mov bh, BIOS_INT_10H_PAGE_NUMBER_0
    mov bl, BIOS_INT_10H_FOREGROUND_COLOR_GM
    int BIOS_INT_10H

    pop bx
    pop ax

    pop bp

    ret

print_string:
    push bp
    mov bp, sp

    push ax
    push bx
    push si

    mov si, [bp+4]

loop_print_string:
    lodsb

    cmp al, NULL_CHARACTER
    je end_print_string

    push ax
    call print_char
    pop ax
    jmp loop_print_string

end_print_string:
    pop si
    pop bx
    pop ax

    pop bp

    ret

load_kernel:
    mov ax, STACK_SEG_BOOTLOADER
    mov ss, ax
    mov sp, STACK_POINTER_BOOTLOADER      

    mov ax, SEGMENTS_BOOTLOADER
    mov ds, ax
    mov es, ax
  
    mov ax, 'p'
    push ax
    call print_char
    pop ax

    mov ax, msg
    push ax
    call print_string
    pop ax

    jmp $

msg db "Hello, world", CARRIER_RETURN, LINE_FEED, NULL_CHARACTER

TIMES 510-($-$$) DB 0

BOOT_SIGNATURE

O código começa e já pula para o label load_kernel, desviando da definição das funções print_char e print_string. O código define então os registradores de segmento e ponteiro da pilha.

Depois, testaremos a função print_char. Defini que a convenção das funções segue o padrão ABI i386, ou seja, os parâmetros são passados na pilha. Isso porque no futuro quero ligar minhas funções com código em C, então preciso seguir a convenção que os compiladores já conhecem.

Então, empilhamos o parâmetro ‘p’ e invocamos a função print_char. Para quem não sabe, a instrução CALL empilha o endereço da próxima instrução na pilha e desvia para o label print_char. Para foco, a função é repetida para melhor entendimento:

print_char:
    push bp
    mov bp, sp

    push ax
    push bx

    mov ax, [bp+4]
    mov ah, BIOS_INT_10H_OUTPUT
    mov bh, BIOS_INT_10H_PAGE_NUMBER_0
    mov bl, BIOS_INT_10H_FOREGROUND_COLOR_GM
    int BIOS_INT_10H

    pop bx
    pop ax

    pop bp

    ret

A função começa ajustando o registro de ativação (isto é, ajustando o valor do registrador bp), e como vamos manipular os registrados ax e bx, estes também são empilhados para restauração posterior. O parâmetro informado é então recuperado da pilha ([bp+4]) e a BIOS é invocada, como já visto. Depois que o caractere é impresso, os registradores ax e bx são restaurados, e o antigo valor de bp também é restaurado. A instrução RET é executada, o que implica em desempilhar o endereço da próxima instrução da pilha (este endereço havia sido empilhado pela instrução CALL, lembra)? Ao retornar, como havíamos empilhado o parâmetro, desempilhamos para que a pilha fique no mesmo estado antes da chamada.

Observe que a chamada para a função print_string acontece da mesmíssima forma. A diferença é que, ao invés de termos empilhado os “valores” que queremos imprimir (como foi o caso do parâmetro ‘p’), agora passamos o endereço de memória de uma string que possui terminação nula (0, ou NULL_CHARACTER definido anteriormente), ou seja, a velha convenção de strings em C. Focando na função print_string:

print_string:
    push bp
    mov bp, sp

    push ax
    push bx
    push si

    mov si, [bp+4]

loop_print_string:
    lodsb

    cmp al, NULL_CHARACTER
    je end_print_string

    push ax
    call print_char
    pop ax
    jmp loop_print_string

end_print_string:
    pop si
    pop bx
    pop ax

    pop bp

    ret

Perceba que a função não é tão diferente assim da função print_char. A diferença é que agora vamos usar o registrador si, e por isso ele é empilhado para restauração posterior.

O endereço da string é então movido para este endereço (instrução mov si, [bp+4]), e a instrução lodsb é executada. Essa instrução pega o conteúdo da memória presente no endereço ds:si e coloca no registrador al. Depois disso, si é incrementado, indo portanto para o próximo caractere automaticamente.

Precisamos testar se o registrador al possui o valor 0/NULL_CHARACTER, indicando que chegamos ao fim da string. Em caso positivo, vamos para o fim da função para limpeza e retorno. Em caso negativo, há um caractere válido para a impressão no registrador al. Nesse caso, podemos usar a função print_char para imprimir esse elemento, certo? Basta apenas empilhar esse parâmetro e invocar a função print_char1 e retornar para o rótulo loop_print_string, para continuar carregando mais caracteres.

Como resultado, temos a string “pHello, world” seguindo do cursor na outra linha da tela. É exatamente o que queremos para o momento!

O código pode ser encontrado nessa branch no meu github.

Anterior

Próximo

Outra coisa é que não tenho a pretensão de ensinar assembly, C ou qualquer coisa do tipo. É bom que você já tenha uma bagagem disso antes de prosseguir (ou pode aprender no processo). Para assembly, por exemplo, há outros materiais que recomendo, como os artigos do Leandro aqui.

Como somos disciplinados, vamos seguir os passos apresentados aqui. O primeiro passo é: “Review project specs, read the necessary documentation, download the start code.”. Ok, aceito os termos, quero continuar :D !

Vamos para o passo dois: “Complete the Quickstart Tutorial to working with Bochs on the lab machines.”

Aqui, duas diferenças importantes. Quero deixar o meu código o mais diferente possível do código dos caras de Princeton, então, além de não o consultar, ainda propus duas alterações, no compilador assembler e no emulador/simulador/virtualizador:

1. Vamos usar NASM em vez do Gnu Assembler; e

2. Vamos usar o QEMU em vez do Bochs.

Em relação ao NASM, na verdade eu já tinha experiência com ele. O as1 eu aprendi fazendo o Projeto 1. Já em relação ao QEMU, confesso que usei muito pouco. Usei muito mais o Bochs, ele tem um mini gdb integrado e tem coisas legais como magic breakpoint2.

Mas isso não vai nos amedrontar certo? Vamos fazer igual o Frank Sinatra, My Way (ou se você for Millenium como eu, a referência é o Limp Bizkit).

Um ponto importante é que programar um kernel é praticamente um Metroidvania: você precisar ir e voltar várias vezes, testar, restartar e frequentemente você vai quebrar algo que já estava funcionando. Se eu postei aqui, é porque eu já passei por essas etapas e já estou mostrando algo funcional.

Ok, vamos começar. Primeiro vamos entender o que o Bochs Quickstart propõe.

Processo de Boot

Essa parte do trabalho quer verificar seu ambiente, se o Bochs está corretamente configurado, se você consegue executar o bootloader dado e ver a letra S na tela, etc.

Vamos recapitular então como é o processo de boot no processador x86. Para detalhes sórdidos, veja aqui. Mas vamos resumir: quando o computador liga, o processador não faz ideia do que está ligado nele: periféricos, discos, quanto de RAM tem no seu sistema, e assim por diante. Por esse motivo, há um conjunto de passos padronizados que são efetuados:

1. O processador executa um código de um chip/firmware ROM que faz toda a checagem do sistema, chamado POST. A maior parte desse trabalho é de responsabilidade da BIOS, e em sistemas mais modernos, UEFI. Há várias checagens de hardware que são feitas nesses passos, como detecção de RAM e outras coisas que não nos interessam agora.

2. Ao finalizar os testes de hardware, a BIOS vai tentar localizar o bootloader. Para isso, ele vai varrer a lista de discos3, na ordem especificada pelo usuário (e na ausência desta ordem, ele usa a default do dispositivo), em busca do disco de boot. A BIOS lê o primeiro setor do disco, a procura de uma assinatura específica (que no caso do x86, é verificar se nos últimos dois bytes do primeiro setor (um setor tem 512 bytes) há o valor 0x55AA. Não há nada de especial neste valor em si, mas se você transformar em binário, verificará que é um padrão 01010101 10101010. Isso indica que alguém intencionalmente escreveu tal padrão neste setor, indicando para o sistema ser o setor de boot.

3. A BIOS coloca esses 512 bytes em um endereço absoluto específico e pré-acordado da arquitetura: 0x7c00. O porquê desse eu não sei, não me pergunte. Mas depois que a BIOS termina esse trabalho, ela faz um far jump para ele e entrega a execução para o bootloader. A partir dai é seu código que está no controle do equipamento.

O projeto apresenta um código para mostrar um caractere na tela, no passo 2 daqui e, se ainda precisar de ajuda, pode consultar algumas dicas aqui. Vamos nos basear nesse código então, mas vamos dar uma simplificada.

global _start

_start:
    mov ah, 0x0e
    mov al, 'S'
    mov bh, 0x00
    mov bl, 0x02
    int 0x10

TIMES 510-($-$$) DB 0

db 0x55, 0xaa

No código acima, definimos o símbolo global _start para que o linker encontre o ponto de entrada do programa. Depois, usamos a função da BIOS de escrita de caractere na tela. os parâmetros são:

ah = 0x0e (sempre)
al = caractere a ser escrito (no caso, ‘S’)
bh = número da página ativa (usamos 0x00)
bl = cor de fundo em modo gráfico (usamos 0x02)

Ai é só executar a instrução int 0x10 e correr para o abraço.

Até esse ponto, o código acima consumiu alguns bytes, não sabemos o quanto necessariamente, nem precisamos (fica de lição de casa você pegar o manual do ISA x86 e descobrir quantos bytes tem até o momento). Mas até a linha 7 acima, esse código não representa um setor de boot, que virá logo em seguida.

Precisamos de vários bytes até preencher 510, e depois inserir dois bytes da assinatura do setor de boot. Essa é a função das próximas duas linhas. $-$$ verifica quanto bytes foram gastos do início do arquivo até a linha anterior, e a diretiva de compilação TIMES repete DB 0 bytes quantas vezes quisermos, no caso, 510-($-$$) vezes. Isso garante que tenhamos 510 bytes preenchidos, e ai finalizamos com a cereja do bolo com os últimos dois bytes 0x55AA.

Ok, e como a gente monta isso. Perceba no passo 3 que eles executam um Makefile que faz várias coisas (imagem abaixo).

Por enquanto, estamos só na primeira parte. Queremos compilar o arquivo para que seja gerado um binário de boot. Portanto, estamos tratando apenas das 2 primeiras linhas do comando. A primeira, gcc -Wall -g -m32 -fomit-frame-pointer -O2 -fno-builtin bootblock.s invoca por baixo dos panos o as. Vamos esclarecer o que esses parâmetros invocados no comando significam.

-Wall significa ligar todos os warnings. O compilador é seu amigo, e se ele tá te alertando de algo, é bom ficar esperto.

-g é necessário para ativar a depuração e para que possamos carregar a tabela de símbolos quando usamos um compilador como o gdb.

-m32 indica a arquitetura do código gerado, no caso, x86 (não compilar para 64bit).

-fomit-frame-pointer tem relação com os registradores de base de pilha, no caso do x86, o bp. Como estamos executando um código em que nós mesmos precisamos gerenciar a pilha, isso indica ao compilador não criar o registro de ativação.

-O2 ativa a otimização em nível de compilação (nem sempre é possível ativar essa opção, nesse nosso caso não fará diferença).

-fno-builtin desabilita a utilização de funções de biblioteca da arquitetura local. Você não pode usar as funções da stdio.h da libc no kernel por exemplo (já que no fim das contas, as chamadas acabam invocando system calls do sistema host, mas o seu código não tem um SO aceitando system calls ainda…). Por isso, avisa ao compilador para não se preocupar com isso.

Esse primeiro comando gerará um arquivo objeto bootblock.o, mas esse arquivo ainda não pode ser utilizado dessa forma. O segundo comando executa o linker (ld) para gerar o binário executável final (but not so much, como veremos a seguir). As opções passadas para o linker foram:

-nostartfiles -nostdlib tem a mesma função do -fno-builtin dito anteriormente, não usar a libc e similares.

-melf_i386 indica o formato do executável, no caso um ELF para x86.

-Ttext 0x0 é um caso interessante, pois este indica o endereço na memória que o segmento de texto (portanto, o código) deve residir. Contudo, já foi dito que este primeiro trecho de código é colocado pela BIOS no endereço absoluto 0x7c00. Então, para que se importar? Primeiro, haverá um próximo passo, não abordado nesse artigo, que irá condensar o bootblock e o kernel em uma “imagem” só que será usada. Isso pode ser visto na imagem acima no comando ./createimage.given —extended ./bootblock ./kernel. O segundo motivo é que as instruções de jump dentro do código do boot podem ser absolutas ou relativas a instrução atual. Dependendo de como você faz o jump no código, ele pode ir para um endereço inválido. Mas a real REAL mesmo é que a imagem é uma coleção de bytes contíguos, e como temos o código bootloader + kernel gerados pelo programa createimage.given, iriamos acabar com o bootloader no endereço 0x7c00 e o kernel no endereço 0x1000, antes portanto, do próprio bootloader! Isso de fato é um problema real para o bootloader, pois se o kernel for muito grande, ele pode começar no endereço 0x1000 e ultrapassar o endereço 0x7c00, sobreescrevendo o bootloader na memória. Isso é uma das coisas que iremos resolver depois inclusive. Mas, agora, precisamos apenas que o compilador e linker não reclamem desses endereços em tempo de compilação, e portanto colocamos o código do bootloader no arquivo ELF no endereço 0x0.

E o que a gente faz com todas essas informações? Vamos começar a montar nosso Lego.

Pré-requisitos

Eu estou usando o Linux no WSL no meu Windows 11. Instalei basicamente os pacotes do QEMU, NASM e GDB com o comando abaixo:

sudo apt install aqemu qemu-system qemu-system qemu-system-x86 virt-manager bridge-utils nasm gdb

Infelizmente não tenho como garantir que mais algum pacote necessário tenha sido instalado anteriormente em outros momentos. Talvez o gcc.

Mas isso não é suficiente para poder rodar o QEMU usando o KVM no WSL. Para isso, ainda é necessário seguir os passos daqui:

1. Adicione o seu usuário ao grupo kvm com o comando abaixo:

   sudo usermod -a -G kvm ${USER}

2. Altere o grupo default do dispositivo /dev/kvm. Para isso edite o arquivo /etc/wsl.conf e adicione a linha abaixo na seção boot:

   [boot]
   command = /bin/bash -c 'chown -v root:kvm /dev/kvm && chmod 660 /dev/kvm'

   Obs: é possível que já exista outras instruções nesse bloco, nesse caso, apenas adicione a linha indicada.

3. Habilite a virtualização aninhada. Para isso, adicione a seguinte linha no bloco wsl2 no arquivo /etc/wsl.conf (se esse bloco não existir, crie-o):

   [wsl2]
   nestedVirtualization=true

4. No fim das contas, o meu arquivo /etc/wsl.conf ficou assim (o seu pode ter ficado diferente dependendo do sistema):

   [boot]
   systemd=true
   command = /bin/bash -c 'chown -v root:kvm /dev/kvm && chmod 660 /dev/kvm'
   
   [wsl2]
   nestedVirtualization=true

5. Feche todos os terminais WSL abertos, abra um Power Shell no windows e reinicie o WSL:

   wsl.exe --shutdown

   Isso foi suficiente para o QEMU funcionar com KVM na minha máquina.

Nosso bootloader

A primeira alteração será mudar a extensão do arquivo de .s para .asm, já que estamos usando o NASM em vez do Gnu Assembler. O segundo ponto é que eu deliberadamente alterei o nome do arquivo de bootblock.s para bootloader.asm, afinal, why not?

Não verifiquei o Makefile da imagem acima, e não sou um especialista em Makefiles, então bear with me, please. Nosso Makefile fica assim (por enquanto!):

all: bootloader

bootloader.o: bootloader.asm
	nasm -wall -O2 -f elf32 -F dwarf -g $<

bootloader: bootloader.o
	ld -nostdlib -g -m elf_i386 -Ttext 0x0 --oformat binary -o $@ $<

clean:
	rm -rf *.o bootloader

Feio né? É o que tem pra hoje. Eu queria muito entender daquelas paradas avançadas de Makefile, .PHONY etc, mas fiz uma busca rápida aqui para usar algumas coisas pelo menos e por enquanto, vamos usar só o $@ e $<. Um dia eu fico bom nisso (ou não, não é minha prioridade :D )

Vamos então entender esse Makefile. Esse tipo de arquivo é executado de forma recursiva. Começando pelo target all, ele buscará o target bootloader. O bootloader, por sua vez, espera que exista o target bootloader.o. O bootloader.o espera que exista o arquivo bootloader.asm. Esse é diretamente compilado pelo comando nasm -wall -O2 -f elf32 -F dwarf -g $<. Para qualquer par de targets e pré-requisitos (neste caso, estamos falando do target bootloader.o e do pré-requisito bootloader.asm na linha 3 do Makefile, é possível especificar o target com $@ e o primeiro pré-requisito com $<. Nesse caso então $< é substituído pelo primeiro pré-requisito do target, e no caso só temos um, bootloader.asm. Se houve mais de um pré-requisito e se quiséssemos referenciar todos, usaríamos a diretiva $^. Não vou entrar a fundo nisso, até porque não tenho o conhecimento necessário, mas essas dicas que estou dizendo foram tiradas daqui.

O comando do target bootloader.o não é muito diferente do original da imagem acima, com exceção do parâmetro -F dwarf, que apenas indica o formato para geração de informações de debugging. Para mais detalhes disso, veja com o comando nasm —help.

Com o bootloader.o criado, o próximo target executado é o bootloader, que invoca o linker na linha 7. O comando também é como o anterior, exceto no formato de saída: --oformat binary. Ou seja, não vamos gerar um ELF, mas sim um binary raw que será executado diretamente pelo emulador. Isso por enquanto, essa situação será alterada no futuro, e o formato de saída desse comando voltará a ser um ELF.

Observe ainda o final do comando: -o $@ $<. Isso indica que a saída/output do comando será o parâmetro $@, que como vimos é o target desse trecho do Makefile e no nosso caso, equivale a bootloader. E a diretiva $< é o primeiro dos pré-requisitos do target, e neste caso só há um, bootloader.o. Isso significa que -o $@ $< é diretamente traduzido para -o bootloader bootloader.o.

O target clean serve para fazer as limpezas de praxe. Como esse Makefile só gera dois arquivos, bootloader.o e bootloader, é suficiente para o nosso caso executar o comando rm -rf *.o bootloader.

Eu gosto de executar os comandos make clean && make simultaneamente, para limpar lixo de execuções passadas e já executar uma compilação nova. A saída desse comando ficou assim:

Nesse momento, os arquivos bootloader.o e bootloader devem aparecer no seu sistema de arquivos.

Temos mais dois arquivos auxiliares para a execução de nosso bootloader. O primeiro é o VM_BoringOS.sh, um arquivo inicialmente criado pelo AQEMU mas que eu adaptei para nosso caso. O conteúdo desse arquivo é o seguinte:

#!/bin/sh
# This script created by AQEMU

CURRDIR=`pwd`

/usr/bin/qemu-system-x86_64 -machine accel=kvm -m 16 -drive file="$CURRDIR/bootloader",index=0,if=floppy,format=raw -boot once=a,menu=on -net nic -net user -rtc base=utc -name "BoringOS" -cpu host -s -S $*

O comando define a variável de ambiente CURRDIR como o diretório do projeto (onde se encontra os arquivos bootloader e bootloader.o). Solicitamos o tipo de virtualização kvm, e 16MB de RAM. Solicitamos que o arquivo bootloader (nosso executável) seja usado como imagem do floppy disk (disquete, para os íntimos) em formato raw. Ele define vários outros valores desimportantes para o momento, mas precisei adicionar o final do comando: -cpu host -s -S. -cpu host indica que o cpu do meu host seja usado (pois ele possui atributos de virtualização), -s habilita a depuração pela porta padrão 1234/tcp, e -S congela a execução assim que a máquina é ligada, aguardando a continuação da execução do comando pelo debugger.

Ao executar o arquivo com o comando ./VM_BoringOS.sh, devemos ver a tela abaixo:

Neste momento o QEMU está pausado aguardando instruções. O bootloader ainda nem foi carregado.

O próximo arquivo auxiliar é o debug_BoringOS.sh. Esse arquivo deve ser executado depois do anterior, para que o gdb possa se atachar ao QEMU e possa emitir comandos.

O conteúdo do arquivo VM_BoringOS.sh é o seguinte:

#!/bin/sh

gdb -ex 'target remote localhost:1234' -ex 'set confirm off' -ex 'add-symbol-file bootloader.o 0x7c00' -ex 'set confirm on' -ex 'hbreak *_start' -ex 'c'

Perceba que usamos o gdb para se conectar no QEMU (1234/tcp), desligamos momentaneamente as confirmações e adicionamos os símbolos de depuração do arquivo bootloader.o alinhado no endereço 0x7c00 (lembre-se que na realidade o segmento de texto está no endereço 0x0). Depois religamos as confirmações e definimos um breakpoint para o endereço _start. Usamos o hbreak *, que significa hardware assisted breakpoint, pois estamos executando em um ambiente virtualizado do KVM. Se fosse diferente disso, o breakpoint seria definido no endereço virtual 0x7c00 que está relacionado ao processo do QEMU, mas não ao nosso bootloader virtualizado. Enfim, hbreak *0x7c00 também funcionaria nesse caso.

Considerando que o comando ./VM_BoringOS.sh foi executado anteriormente e está pausando aguardando comandos, executando o comando ./debug_BoringOS.sh, temos:

Do lado esquerdo, temos que o QEMU adiciona os símbolos do bootloader.o e define o breakpoint de _start. Ele então manda o QEMU continuara execução, e o QEMU, do lado direito, executa o POST/BIOS, busca e encontra o setor de boot no disquete montando (nosso arquivo bootloader). Ele então carrega o conteúdo desses 512 bytes a partir do endereço 0x7c00 e faz um far jump para esse endereço. Nesse momento, o QEMU encontra nosso breakpoint definido anteriormente, para a execução ai.

Ao disparar comandos s (ou step) no gdb, navegamos pelos nossos comandos do arquivo bootloader.asm, e o resultado é um S impresso na tela do QEMU, que é o que queríamos fazer desde o início!

Quanta trabalheira só para isso. Boring, não é mesmo? No próximo artigo, vamos criar o código para juntar o bootloader e um kernel safado, baseado no createimage do Projeto 1. O código pode ser encontrado nessa tag aqui no github ou nesse commit específico.

Anterior

Próximo

Eu tive ótimos professores na faculdade, e de tudo que eu aprendi de computação, o que eu mais gostava sem dúvida eram matérias de programação de baixo nível. Meu Professor de Linguagem de Montagem na UFMS, Prof. Ronaldo, lecionava também matérias de Redes de Computadores e até mesmo Sistemas Operacionais, igualmente interessantes.

Haviam outros professores igualmente habilidosos, e me recordo como se fosse hoje de aprender quaternions1 na disciplina de Computação Gráfica com o Prof. Pagliosa. O motor gráfico que fizemos (entenda o “nós” aqui como ele - o professor, no fim das contas era um boilerplate onde precisávamos completar trechos específicos) resultou em um dos trabalhos mais interessantes, e ao mostrar o resultado para a minha namorada à época - hoje, esposa - ela não pareceu tão impressionada, e me lembra até hoje de ter ficado feliz de ter desenhado uma hemácia em 3D.

Deixando as digressões de lado, os trabalhos de Linguagem de Montagem eram fascinantes, para quem gostava obviamente. Nem todos os alunos compartilhavam da minha opinião de que eram divertidos. É o tipo de matéria que se você não tem interesse ou perdeu alguma aula, pode ficar sem acompanhar o restante da disciplina. Principalmente para um estudante no segundo ano do curso de Ciência da Computação, tais trabalhos eram difíceis de entender, assimilar e codificar. Ainda são, na real.

Lembro dos trabalhos que tivemos que fazer até hoje. O primeiro era um dissassembler: dado um executável em formato raw binary (isso porque existem outros tipos de executáveis binários, como o ELF2 ou COFF3, para citar alguns), a missão era ler arquivo binário, identificar as operações e operandos, e imprimir o código equivalente em assembly no formato NASM4. Para isso foi necessário ler o manual do processador x865, descobrir o opcode de cada uma das instruções, identificar o tamanho da instrução na memória (quantos bytes ocupava), os operandos, etc. Pois é, para a surpresa de ninguém, a arquitetura CISC dos processadores x86 adicionam uma complexidade para a decodificação de suas instruções. Este trabalho todo feito em C, e pela primeira vez, tivemos contato com ponteiros de função, com o opcode servindo de índice para chamarmos a função que decodifica a instrução.

O segundo foi implementar o tipo BigInteger6, que existe em Java, em assembly. Na época, não havíamos tido a disciplina de Java. E o problema em si era, dado um número inteiro de tamanho qualquer, possivelmente maior que os 32bit dos registradores que possuíamos, e fazer as operações básicas de adição, subtração, multiplicação e divisão com tais dados.

O terceiro foi implementar uma lista ligada em assembly.

O quarto foi o mais interessante. O professor fazia uma mini bootloader e nossa missão era salvar o endereço da interrupção da BIOS que fica no vetor de interrupções (primeiros endereços da memória), substituíamos por uma função nossa, que era encarregada de mostrar um relógio no canto inferior esquerdo da tela. Depois que nossa função terminava, nós invocávamos a função original que havia sido salva. Dessa forma, a cada tick do relógio, nosso relógio era atualizado na tela. Trabalhávamos em conjunto com a interrupção do teclado, para que pudéssemos escrever coisas na tela e ver o relógio funcionando simultaneamente.

No fim das contas, aqueles eram tempos mais fáceis. Muito tempo depois, o Prof. Ronaldo ministrou a disciplina de Sistemas Operacionais para a pós-graduação. Eu há muito tinha terminado o mestrado, e já tinha cumprido os créditos do Doutorado. Mas como ele sabia do meu interesse no tema, eu assistia às aulas como ouvinte, fazendo os trabalhos também.

Para a minha surpresa, o prof. aproveitou o curso COS 318 de Princeton7, e portanto faríamos um kernel de verdade!

Fizemos todos os 6 trabalhos, e nunca aprendi tanto sobre SO como nessa ocasião. E percebi o quanto que eu achava que sabia, mas que de fato não era verdade, ou das coisas que tinha uma ideia de como as coisas funcionavam mas não sabia exatamente como era implementado na prática.

Chegou a hora de revisitar essas páginas e fazer um kernel do zero (não falei em quanto tempo). Já batizei o rapaz, e ele tem o nome Boring OS por um motivo muito simples: ele não fará nada impressionante, a diversão está na construção. Se você notar os 6 projetos de Princeton, notará por exemplo que não há nada de redes, ou interfaces gráficas. E como até chegar lá é um loooooongo caminho, provavelmente aqui também não terá nada do tipo.

Um dos desafios auto impostos por mim a mim mesmo é justamente não usar nem consultar nada do que fiz na época. Isso é um trabalhão, já que entre os projetos, há muito boilerplate de códigos já feitos pela galera da universidade americana. Nada de lá será usado aqui, até por questões de plágio etc. Portanto, vaguearemos no escuro apenas com as instruções da página.

No próximo artigo começaremos a por a mão na massa, no Projeto 1: Bootloader8! Nos vemos lá.

Próximo

Subscreva agora