Chapter 7. Debugging

Table of Contents

User-level Debugging
Kernel-level Debugging

User-level Debugging

gdb

gdb is the GNU debugger. It is very intimidating to most people, but there really is no reason for it to be. It is very well done for a command line debugger. There is a nice GUI front end to it known as DDD, but our purposes will require a closer relationship with the command line.

gdb has a nice built-in help system organized by topic. typing help will show you the categories. The main commands we will be interested in are run, break, cont, stepi, finish, disassemble, bt, info [registers/frame], and x. Every command in gdb can be followed by a number N, which means repeat N times. For example, stepi 1000 will step over 1000 assembly instructions.

-> Example using gdb to set breakpoints in functions with and without debugging symbols.

-> FIXME: Test watchpoints

Using windbg

WinDbg is part of the standart Debugging Tools for Windows that everyone can download for free from. Microsoft offers few different debuggers, which use common commands for most operations and ofcourse there are cases where they differ. Since WinDbg is a GUI program, all operations are supposed to be done using the provided visual components. There is also a command line embeded in the debugger, which lets you type commands just like if you were to use a console debugger like ntsd. The following section briefly mentions what commands are used to do common everyday tasks. For more complete documentation check the Help file that comes with WinDbg.

Breakpoints

Breakpoints can be set, unset, or listed with the GUI by using Edit->Breakpoints or the shortcut keys Alt+F9. From the command line one can set breakpoints using the bp command, list them using bl command, and delete them using bc command. One can set breakpoints both on function names (provided the symbol files are available) or on a memory address.

Stack operations

Reading and Writing to Memory

Reading memory is accomplished with the d* commands. Depending on how you want to view the data you use a specific variation of this command. Let's look at an example of what might be a normal action. More to follow

Tips and tricks

Using softice

Kernel-level Debugging

Kernel-level debugging is useful if you want to attempt to figure out how a particular device driver is working, or if you want more information on a particular kernel entry point/API. Unfortunately, the support for kernel debugging is much better under Windows than it is under Linux. Fortunately, under Linux we have the source :)

Using kd

Using softice

Using gdb

Using the kernel profiling/hacking option