Kernel Debugging: Difference between revisions
Jump to navigation
Jump to search
Added information on how to write logfiles over the serial port in QEMU
| [unchecked revision] | [unchecked revision] |
(Added information on how to write logfiles over the serial port in QEMU) |
|||
Line 42:
Another virtual machine called Simics (https://www.simics.net) is capable not only of breakpoints and displaying register information, but it is also capable of opening a port for use with debugging with DDD (the simics command is 'gdb-remote'). Using this combination, it is possible to see your C source code as you step through the OS! However, the Bochs virtual machine is much faster at executing the OS than Simics and thus serves as a better virtual machine to ''run'' the OS, while Simics is the better ''debugger'' for those hard to find problems.
==
=== Writing logfiles with QEMU ===
QEMU allows you to redirect everything that you send to COM1 port to a file on your host computer. To enable this feature, you have to add the following flag when launching QEMU:
-serial file:serial.log
... while "serial.log" is the path to the output file. Once you have this feature enabled, you can write log entries by simply [[Serial Ports|writing characters to the COM1 port]] (reading from the file over the serial port is not supported).
=== On real hardware ===
When your real computer resets due to a programming error, anything you might have put on the screen will instantly vanish. If you're tampering with the video card, you will often find yourself with no visual debugging method at all. If you have a pair of computers connected with a null-modem cable, you can instead send all debug statments over the serial port instead and record them on your development machine that is more stable. Using an actual serial terminal works just as well. It requires a bit of additional cabling, but it works fairly simple and can prove to be a very good replacement for a VM log.
==== With remote debugger / GDB ====
Since serial works two ways, you can also control your kernel remotely in case of problems. This can be a simple interface, but you can also attach GDB onto the serial port and potentially get a full blown debugger running.
| |||