Writing or porting a debugger to a new operating system is a difficult and lengthy process, and most likely you will want to use a debugger well before you're ready to host one. It would be great if you could use gdb or a similar debugger running on another machine, while your operating system ran on the target machine.
On the debugging (host) machine, you need to:
init_serial();
and
set_debug_traps();
calls to the kernel, to be executed
after you set up exception handling; andThe gdb stub routines that you need to provide may have been partially provided for you. They include polling serial routines to read and write a character, and a routine to flush the instruction cache (usually just a jmp instruction). You still need to fill in the exceptionHandler() and memset() routines, and feel free to rewrite any part of the example stub routines.
Once you have the debug traps installed and working correctly, your operating system will appear to hang whenever it encounters an exception. However, it is merely waiting in the polling serial driver for a response from the host machine. To debug the kernel in this state, start up the gdb cross-debugger, and at the prompt, type:
target remote /dev/tty0
where /dev/tty0 is the name of the serial port on the host machine. gdb
will then try to connect to the target machine, and if all goes well it
will display where the fault occurred. You should then be able to use gdb
just as though you were debugging a local program. Stubs provided with gdb for different platforms:
Example stub code that needs to be tailored to your OS:
The i386-stub.c file has been slightly modified to clean up unresolved references and comment out some unimplemented libc functions (namely, fprintf() and printf()).