Kernel Debugging: Difference between revisions

[unchecked revision][unchecked revision]
(FAQ entry by another name)
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.
 
== Using aVia serial null-modem between GDB and your OScable ==
 
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.
It is possible to add stubs to your OS kernel so that it can be debugged ''remotely'': Your
kernel is running on machine A, and you run GDB on machine B connected to A via a null-modem cable.
 
=== With remote debugger / GDB ===
This is a bit tricky, since it requires additional hardware, and special support coded into
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.
your kernel. You might want to read the [http://www.kernelhacking.org/docs/kernelhacking-HOWTO/indexs09.html kernel hacking how-to]
 
and (at minimum) [http://sources.redhat.com/gdb/current/onlinedocs/gdb_18.html#SEC144 chapter 17 of the GDB manual].
This is however rather tricky, since it requires additional hardware, and special support coded into your kernel. You might want to read the [http://www.kernelhacking.org/docs/kernelhacking-HOWTO/indexs09.html kernel hacking how-to] and (at minimum) [http://sources.redhat.com/gdb/current/onlinedocs/gdb_18.html#SEC144 chapter 17 of the GDB manual], and chances are likely that your debugger will introduce even more bugs at first.
 
== Use gdb with Qemu ==
1,490

edits