Linux Device Drivers

Using a Debugger

The last resort in debugging modules is using a debugger to step through the code, watching the value of variables and machine registers. This approach is time-consuming and should be avoided whenever possible. Nonetheless, the fine-grained perspective on the code that is achieved through a debugger is sometimes invaluable. In our context, the code being debugged runs in the kernel address space—this makes things harder, because it’s impossible to step through the kernel unless you remote-control it. I’ll describe remote control last because it’s rarely needed when writing modules. Fortunately, it is possible to look at variables in the current kernel and to modify them, even without remote control.

Proficient use of the debugger at this level requires some confidence with gdb commands, a minimal understanding of assembly code, and the ability to match source code and optimized assembly.

Unfortunately, gdb is more useful for dealing with the kernel proper than for debugging modules, and something more is needed to apply the same capabilities to modularized code. This something is the kdebug package, which uses the ``remote debugging'' interface of gdb to control the local kernel. I’ll introduce kdebug after talking about what you can do with the plain debugger.

Using gdb

gdb can be quite useful for looking at the system internals. The debugger must be invoked as though the kernel were an application. In addition to specifying the kernel’s filename, you should ...