Use the GDB command line debugger to debug C/C ++ programs

Most people use the IDE integrated with the debugger, but the most famous debugger in linux is the command line C/C ++ debugger GDB. However, similar to other command line tools, DGB requires some exercises to be fully mastered. Here, I will tell you the basic situation and usage of GDB.

Install GDB

GDB is available in most release repositories.

Debian or Ubuntu

$ Sudo apt-get install gdb

Arch Linux

$ Sudo pacman-S gdb

Fedora, CentOS or RHEL:

$ Sudo yum install gdb

If you cannot find it in the repository, you can download it from the official website.

Sample code

When learning GDB, it is best to have a copy of code for hands-on testing. The following code is a simple example I have written. It can reflect the features of GDB. Copy it and perform an experiment-this is the best method.

# Include <stdio. h>
# Include <stdlib. h>
 
Int main (int argc, char ** argv)
{
Int I;
Int a = 0, B = 0, c = 0;
Double d;
For (I = 0; I <100; I ++)
{
A ++;
If (I> 97)
D = I/2.0;
B ++;
}
Return 0;
}

Use of GDB

First of all, you need to use the "-g" option of the compiler to compile the program so that the executable program can run through GDB. Run the following statements to start debugging:

$ Gdb-tui [executable program name]

You can use the "-tui" option to display the code in a beautiful interactive window (so it is called "text user interface TUI"). You can use the cursor to control the code in this window, at the same time, enter the command in the following GDB shell.

 

 

Now we can set breakpoints anywhere in the program. You can use the following command to set a breakpoint for a line of the current source file.

Break [row number]

Or set a breakpoint for a specific function:

Break [function name]

You can even set conditional breakpoints.

Break [row number] if [condition]

For example, in our sample code, you can set the following:

Break 11 if I> 97

 

 

In this way, the program stays on the "a ++" statement after 97 cycles. This is very convenient, avoiding the need to manually cycle 97 times.

Last but most importantly, we can set an "observation breakpoint". When the observed variable changes, the program will be stopped.

Watch [variable]

Here we can set it as follows:

Watch d

When the value of d changes, the program stops running (for example, when I> 97 is true ).

After the breakpoint is set, run the "run" command to start running the program, or as follows:

R [program input parameters (if any)]

In gdb, most command words can be abbreviated as a letter.

No surprise, the program will stay in 11 lines. Here, we can do something interesting. The following commands:

Bt

The backtrace function allows us to know how the program reaches this statement.

 

 

Info locals

This statement displays all local variables and their values (you can see that I have not set the initial value for d, so its current value is any value ).

Of course:

 

 

P [variable]

This command can display the value of a specific variable, and further:

Ptype [variable]

The type of the variable is displayed. So here we can determine that d is double type.

 

 

Now that we have reached this step, I may wish to do this:

Set var [variable] = [new value]

This will overwrite the value of the variable. However, you cannot create a new variable or change the type of the variable. We can do this:

Set var a = 0

 

 

Like other excellent debuggers, we can perform one-step debugging:

Step

If you run the preceding command to the next statement, it is possible to enter a function. Or use:

Next

This allows you to directly run the next statement without entering the Subfunction.

 

 

After the test, delete the breakpoint:

Delete [row number]

Run the program from the current breakpoint:

Continue

Exit GDB:

Quit

In short, with GDB, you don't have to pray to God during compilation, and you don't have to sacrifice blood when you run it, and you don't need printf ("test") anymore. Of course, what we are talking about here is not complete, and the functions of GDB are far more than that. So I strongly recommend that you study it more deeply. I am now interested in integrating GDB into Vim. At the same time, here is a memo that records all the command lines of GDB for reference.