How to Use the GNU Debugger (GDB)

The GNU Debugger, or GDB, is a debugging tool used to debug programs written in C, C++, Fortran, Go and other compiled programming languages. GDB allows users to inspect what is happening inside a program while it runs by setting breakpoints, stepping through code, examining variables and controlling execution flow.

GDB is especially useful for identifying and resolving bugs efficiently in complex codebases, and can help users see how their code works in situations where various outcomes are possible. It runs on many Unix-like systems and is available for free under the GNU General Public License.

RelatedCLI Commands: An Introduction With Examples

GDB Commands to Know

There are multiple commands to use in GDB. Some of the most common GDB commands include:

• run or r: Runs the program until a breakpoint or error.
• break or b: Places a breakpoint. 
• next or n: Runs the next program line, stepping over function calls.
• list or l: Prints next ten lines of source code.
• -g: Generates line-by-line information that a debugger can use against source code (this command is included in the line of code example above).
• -o: Converts any GDB output into a file that can then be used in other software to help developers analyze content.
• enable/disable: Lets a programmer start or stop individual breakpoints to allow the system to work as necessary.
• -q: Quiet the startup message on GDB if necessary.
• --args: Create new command-line arguments in the program with this command. New arguments can dispute possible results.
• --pid: Sometimes an application might become stuck and unable to keep working. The --pid command lets the user review individual processes in the program and see what specific problems are causing loading delays.
• nostop: GDB will not stop the program when it reaches a signal or other action. The debugging system will keep running the program, letting the programmer see if certain changes can impact the project in any form.
• stop: The GDB setup will also stop the program when a signal appears as necessary. The program should announce when it stops.

Users can check the GDB program for details on other commands to apply and the best times to establish them.

How to Use GDB for Debugging

Here is a step-by-step guide to using GDB on a program of your own:

1. Install GDB On Your System

 The first step is ensuring that GDB is downloaded and installed on your computer. It can be installed to work on Linux, macOS (via Mac Ports) and Windows.

2. Prepare Your Code for Debugging

Before you can use GDB, you must compile your code with the -g flag. This flag tells the compiler to include debugging information — such as variable names, function names and line numbers — in the compiled executable. Without this information, it may be difficult for GDB to provide a meaningful source-level debugging experience.

For a C++ file named STL_vector_int_2.cpp, you would use the following command in your terminal: 

g++ -g -o vector_test STL_vector_int_2.cpp

• g++: The C++ compiler.
• -g: The flag to include debugging information.
• -o vector_test: Specifies the name of the output executable file.
• STL_vector_int_2.cpp: The source code file to be compiled.

3. Start GDB and Load the Program

After compiling, you can start GDB and load your executable by typing gdb followed by the executable’s name.

gdb vector_test

This will launch the GDB environment and you’ll see the GDB prompt: (gdb).

4. Set a Breakpoint

A breakpoint is a marker you place in your code to tell GDB where to pause execution. This allows you to inspect the state of your program at a specific point.

To set a breakpoint at a specific line number (for example, line 15), you use the break or b command.

(gdb) b 15

Alternatively, you can set a breakpoint at the beginning of a function, such as main:

(gdb) b main

5. Run the Program

Once your breakpoint is set, you can start the program’s execution using the run command.

(gdb) run

The program will run until it hits the breakpoint you set. At this point, GDB will pause execution and display a message showing the location where it stopped.

6. Navigate and Inspect Your Code

When GDB stops at a breakpoint, you can use various commands to inspect variables, step through code and move through the program’s execution.

• print or p: Displays the value of a variable.

(gdb) p my_variable

• list or l: Displays the source code around the current line of execution.

(gdb) list

• next or n: Executes the next line of code, but steps over any function calls. This means it will not enter the function’s code.
• step or s: Executes the next line of code, and steps into any function calls. This is useful for debugging a function line by line.
• continue or c: Resumes execution until the next breakpoint is hit or the program finishes.

7. Fix the Bug and Run the Updated Program

After identifying and fixing a bug in your source code, you do not need to exit GDB. You can recompile from within the debugger and then run the updated program.

(gdb) shell make
(gdb) run

Advanced GDB Techniques

While basic GDB commands like run, break and next are essential, mastering a few advanced techniques can dramatically improve your debugging efficiency.

Here are some advanced GDB techniques to know about for in-depth debugging:

Conditional Breakpoints

Conditional breakpoints stop program execution only when a specified condition is met. This is invaluable when a bug occurs in a loop or function that is called multiple times, as you don’t have to manually step through every iteration.

To set one, use the break command followed by the condition:

# Break at line 10 only if the variable 'i' equals 500
(gdb) break 10 if i == 500

# Break in a function 'process_data' only if 'input_size' is negative
(gdb) break process_data if input_size < 0

Watchpoints

A watchpoint is a type of breakpoint that stops execution whenever the value of a variable or a memory address changes. This is often more efficient than setting conditional breakpoints in every function that might modify a variable. 

Watchpoints are especially useful for tracking down where an unexpected variable change or corruption is happening. For example:

# Stop when the value of the variable 'my_counter' changes
(gdb) watch my_counter

# Stop when the memory location at a specific address is written to
(gdb) watch *0x7ffffffee018

Tracing

Tracing allows you to record a program’s execution without stopping it, allowing you to inspect the program’s history and even run backward through the code. This is a useful feature for understanding complex code interactions.

The primary tracing command is record. Once activated, GDB will record the program’s state, for example:

# Start recording the program’s execution
(gdb) record

# Run the program until the next breakpoint or completion
(gdb) continue

# Replay the execution backward one step
(gdb) reverse-step

# Replay the execution backward one line
(gdb) reverse-next

Examining Memory

The x command (short for examine) lets you directly inspect raw memory at a given address in a program. This is helpful for debugging pointers, memory leaks and corrupted data structures.

The syntax is x/NFU address, where:

• N is the number of units to display.
• F is the display format (e.g., x for hexadecimal, d for decimal, i for instruction).
• U is the unit size (b for byte, h for halfword/2 bytes, w for word/4 bytes, g for giant word/8 bytes).

# Examine 16 bytes starting at the address of 'my_array' in hexadecimal format
(gdb) x/16xb my_array

# Examine the 8-byte value at the address of a pointer 'ptr'
(gdb) x/xg &ptr

Debugging Multi-Threaded Applications

GDB provides commands for navigating and debugging programs with multiple threads. This can help identify race conditions, deadlocks and other concurrency-related bugs.

• info threads: Displays a list of all active threads and their current state.
• thread <thread_id>: Switches the current debugging context to the specified thread.
• break <file>:<line> thread <thread_id>: Sets a breakpoint that will only trigger when the specified thread reaches that line.

# List all running threads
(gdb) info threads

# Switch debugging focus to thread with ID 2
(gdb) thread 2

# Set a breakpoint on line 42 in main.cpp, but only for thread 3
(gdb) break main.cpp:42 thread 3

Debugging Core Files

A core dump is a file containing a snapshot of a program’s memory at the moment it crashed. GDB can load and analyze this file, allowing for post-crash debugging to determine why the program failed without needing to reproduce the bug.

To open a core file with GDB, provide the executable and the core file as arguments:

# Debug a core file named 'core_file' from an executable 'my_app'
$ gdb my_app core_file

Once loaded, you can use commands like backtrace (bt) to see the call stack at the time of the crash, and print to inspect the values of variables and arguments that led to the crash.

What Is ./Test in GDB?

In GDB, the ./test command executes a program named test located in your current directory. It’s a fundamental command to tell the operating system to run that specific file. The ./ portion is a security measure that ensures the program is launched from the current location and not another one found in your system’s PATH.

As a note when using the ./test command, the program will run to completion or crash. It won’t provide details on its internal data or why it might have failed. Any information you see, like output to the screen or error messages, is produced by the program’s own code.

To review code and potential bugs in the executed program, debugging is required. Here’s the difference between the two actions:

• Execution with ./test in GDB is for seeing the program’s final result.
• Debugging with GDB allows you to pause the program’s execution, inspect variables in real time and step through the code line-by-line to find the source of a bug.

More in Software Engineering5 Ways to Find the Index of a Substring in Python

Why Use GDB?

All programmers and coders need powerful tools to check their work. This is why debuggers are so popular in the coding community. GDB is one of the more powerful tools that programmers and coders can use to debug their work, find errors and fix outcomes. 

GDB, like other debuggers, can help determine if code is working or if changes are necessary. It offers a variety of powerful commands and modifiers, and works on every major operating systems, making it a valuable tool for programmers or coders to keep in their toolbox.

Frequently Asked Questions