Debugging

Troubleshooting an operating system is more difficult than troubleshooting an application running as a process. For the simplest form of debugging, insert informative output into the code that displays memory addresses, variable contents, and other state information on the screen.

In order not to mix the regular screen output with debug information all the time, you can write to a virtual serial or parallel port in the emulator and redirect it to a file (or a terminal window).

For Qemu, the additional -serial mon:stdio option ensures that output appears on the serial port in the terminal from which the emulator was started. Bochs lets you redirect serial output to a file, if you add a matching line in the Bochs configuration (.bochsrc) (Listing 4). Instead of a file, the target can also be a terminal window via mode=term, dev=/dev/pts/5, whose device file the developer queries in advance with tty.

com1: enabled=1, mode=file, dev=serial.out

Listing 5 shows a simple implementation of the uartputc function, which sends a single character to the first serial port (COM1): It uses the 0x3f8 port for this purpose. The functions used here, outportb and inportb, execute the x86 instructions out and in via inline assembler.

#define COM1_BASE 0x3f8 // first serial port
void uartputc (char c) {
  while (inportb (COM1_BASE+5) & 0x20) == 0) ;
  outportb (COM1_BASE+0, c);
}
char inportb (short port) {
  char wert;
  asm ("inb %1, %0" : "=a" (rv) : "dN" (port));
  return value;
}
void outportb (short port, char value) {
  asm ("outb %1, %0" : : : "dN" (port), "a" (value));
}

Bochs has an integrated text mode debugger, which is made more convenient by a graphical frontend (in the bochs-x package). At the bottom (above the status line), there is an input line in which you can set a breakpoint, for example, using lb 0xc0101496. When the emulated computer jumps to this address, Bochs interrupts the execution.

By pressing F11, the developer can now execute one machine-language command after another, step by step; Bochs displays the disassembled code in the middle column (Figure 3). You can find the relevant address up front by looking at the symbol table, which the command from Listing 6 generates from the kernel binary.

$ objdump -M intel -D kernel.bin | grep -e '^[^ ]* <' | sed -e 's/<//' -e 's/>://'

Figure 3: The Bochs GUI displays register contents, disassembled OS code, and selected contents (here the GDT).

The kernel can also be debugged with Qemu. If Qemu is started with the option -s, it listens locally on TCP port 1234 and can be remotely controlled with Gdb. Next call the debugger with the kernel binary as a parameter – it is now aware of the symbolic names, i.e., functions and variables – and then establish a connection to the kernel from within Gdb by typing target remote tcp::1234. You can then stop the kernel in Gdb and display the assembler code of individual functions, using disassemble, for example (Figure 4).

Figure 4: Qemu does not come with its own debugger, but you can use it with Gdb.

Outlook

By experimenting with the example files for this article [5], you can easily add additional features. If you want to turn this project into a real Unix system with multitasking and some standard shell tools, take a look at Ulix [15]: I developed the Unix-style 32-bit system for use in computer science studies and documented the complete source code in a 700-page book [16]. The book also introduces readers to the theoretical basics of operating systems. An amazingly long overview of other hobby operating systems is available at OSDev.org [17]. If you want to build your own kernel, you're not alone.