The GNU Debugger (GDB)

Hello, and today, I’d like to guide you through the GNU project DeBugger, also known by its command line name of GDB. GDB is a debugging program that can stop and start your program executable, and analyze it’s variables and methods as it runs. Using GDB, you can stop your program at break point to study and analyze the current state of the executable, and get a better glimpse of any issues or errors in the program. A debugger is the best tool to find bugs like faulty variable values, and for finding the reason certain programs crash.
 

In order to work with GDB, you will need to compile your programs with the ‘–g’ flag on the command line. This will enable the gdb to read the source file along with the executable by compiling the necessary information from the source with the executable, and it is necessary to enable and access a lot of the features available in gdb. For this tutorial, please compile the tokenizer code from the last tutorial for our experiment today, like so:

G++ -Wall commandlinearg.cpp –g –o lineArg.exe
 

This will set the program just compiled with the necessary debugging information for GDB to perform actions such as back tracing and break points. It will also enable GDB to print variables found in the program as it runs, so that we may analyze them for possible errors, or to simply see them perform in action.

Now, in the directory of the executable you’ve just compiled, type GDB executableName.exe. You can also This will run the debugger in the command line, with the executable loaded and ready for running. Before running the executable, set some break points by using the keyword break, followed by either a number, or a function name from inside the source used to compile your executable (or in case there are multiple files used break filename.*:number or method).

 If you use the number, the number used will represent a line in the source file used. It isn’t necessary to have access to the source, because everything is included in the executable, or the object file. For our example executable, please use break 27 and break wordCounter, which will set two break points at the line specified, and at line 43, the beginning of the wordCOunter method.

Also, before running the program, type display argc. This will display the value of the command line argument argc, which gives the number of arguments being passed to the program. This value will be displayed every time the program stops execution at a break point.

Now, to run the executable with an argument, type run “Command Line Argument” which will run the executable with “Command Line Argument” as a parameter.

Execution stops first in the wordCounter method; when it does, it will display the argc variable, and the value it holds (it should be 2). It should also display the current line the debugger has stopped at, along with display the source line. To see the next line of code, type step. This will move the program and debugger to the next line of code, redisplay argc along with the line of code at the next line of the source. Type step again to get to the next line, this will initialize the wordCount variable to one, like in the source. Type print wordCount to confirm the integer has been initialized. When your finished, type bt or backtrace to see the path of execution for methods used in this program. This command will display the methods used up to the current position of the program the debugger is in. When your finished with this method, type continue to finish the method and continue back to main, to the next break point, at line 27.

Use this point to practice the command I’ve shown you; use the source file as a reference, and try to use break with a file name to practice it’s use with multiple file when the time comes. Also, try using the debugger with other executables, like the other executables in previous tutorials. Using the debugger is extremely useful for programmers, and learning this will help you figure out how a program ticks, and where problems are at to fix. And getting comfortable with GDB is a lot quicker that going in-between many different debuggers like in Visual Studio, or other IED-based debuggers.