Table of Contents
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
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 can be set, unset, or listed with the GUI by using -> 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.
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
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 :)