7. Part 5: Learn how to debug with gdb

For those of you who are not robots or cyborgs, you will undoubtedly introduce bugs into your source code at some time or another. Debuggers are tools that facilitate the finding of bugs, and it will make your life much easier if you learn how to use one. In this section, we will introduce the GNU gdb debugger, though you are welcome to use whatever debugger you would like (hint: change the values of the DBX and DFLAGS environment variables). We strongly suggest against using the null debugger, i.e., no debugger at all.

Normally, to start gdb you would type gdb program. Within gdb, you would type run arguments to start the program. However, to make it so you don't ever need to type in the prodigious argument lists used in the runs in the exercises, we support a different start-up procedure. With each script (e.g., lab0p4.sh), we support the flag -debug which starts up the given program inside of gdb. In addition, all of the command-line arguments are cached somewhere so that you only need to enter run (or simply r) to start the program.

To learn the basics of gdb, check out this [gdb tutorial] or find other tutorials on the web via Google; you can also get some documentation within gdb by typing help.

For this part of the lab, you will need to answer the question posed in lab0.txt. To do this, we suggest you learn how to set a breakpoint (via the breakpoint or b command) and how to print the value of a variable (via the print or p command). Some other commands that you should know about (just on general principle) are cont, step, next, where, up, down, and finish.

Hint: it's generally easier to set breakpoints on line numbers rather than function/method names. If you do want to set a breakpoint on a method name, the syntax is
b namespace::class::method
You only need to specify namespace if the class is in a namespace. In our case, the class FEScale is in the namespace Zee, as will be most classes we will define in the labs. Another hint: learn the distinction between step and next. (In most cases, next is the more useful command.)

In Lab 1, it will be very useful to be able to examine the contents of objects like inBuf when in the debugger. You might want to see what the following commands do within gdb (when stopped in a context where inBuf is defined):
p inBuf.get_frame_count()
p inBuf.get_dim()
p inBuf[12][13]
p inBuf[12][13]@5

For future reference, in the interest of preempting debugging questions, here are three procedures you should perform before asking for help in finding a bug: