Linux debugger–gdb use

Linux debugger–gdb use

  • 1. Background knowledge
  • 2. Use gdb
    • 2.1 Enter gdb
    • 2.2 Exit gdb
    • 2.3 View code
    • 2.4 Execution program
    • 2.5 Break point
      • 2.5.1 Breakpoint in the specified source file:
      • 2.5.2 Break points at functions in specified source files
    • 2.6 View breakpoints
    • 2.7 Delete breakpoints
    • 2.8 Enabling and disabling breakpoints
    • 2.9 Go statement by statement after encountering a breakpoint
    • 2.10 Step by step after encountering a breakpoint
    • 2.11 During debugging, view the value of variables
    • 2.12 Jump to the specified location
    • 2.13 Running the current function is completed
    • 2.14 Run directly from one breakpoint to the next
    • 2.15 Call stack
    • 2.16 Changing the value of variables during debugging

1. Background knowledge

  • We have two modes when running our code: Debug mode and Release mode.
  • To be debugged, the release mode of this code must be Debug
  • In Linux we use gdb for debugging

Install gdb (here I am using CentOS 7.8):

yum install -y gdb
  • Use gcc to compile code in a Linux system, and the generated executable program is in Release mode by default.

Verification: Here, our make/makefile compiles the test.c file I wrote and generates the executable file test.

  • When compiling in Debug mode using gcc in Linux, you need to use the – g option:
gcc -o generates executable file name source file name -g

The – g option here is to specify the gcc compiler to compile the source file in Debug mode.

  • A more vivid distinction between Debug mode and Release mode:

Method 1:

When Debug is released, be sure to add Debug information inside the executable program, otherwise it cannot be debugged

Therefore: The size of the executable file formed by Debug > The size of the executable file formed by Release

Method 2:

Use instructions:

readelf -S executable program file name | grep -i debug

Function: The format of the executable program formed in Linux is the ELF format, and readelf -S is to read the executable program, and the following is to filter out the Debug information in the file through the pipeline. If there is Debug information, it means that the executable program file was compiled in Debug mode, otherwise it is Release mode.

2. Use gdb

2.1 Enter gdb

gbd debugs executable files (generated in debug mode)! ! ! 

gdb executable program

2.2 Exit gdb

quit

2.3 View code

list
list can also be abbreviated as l

Looking at the first line of code:

list 0 or list 1 (up to ten lines printed each time)

The last result will be automatically recorded in gdb, as shown below. After executing list 0 once and pressing Enter, the remaining code will be printed until it is all displayed.

2.4 Execution program

instruction:

run
It can be abbreviated as: r

2.5 Breakpoint

instruction:

 break code line number
 break can be abbreviated as b

Function: Break point at which line of code

We know that executable program files can be compiled from multiple source files.

2.5.1 Break point in specified source file:

instruction:

b source file name: line number

2.5.2 Breaking points at functions in specified source files

instruction:

b source file name: function name

2.6 View breakpoints

instruction:

info break

2.7 Delete breakpoints

instruction:

delete break breakpoint number
delete break can be abbreviated as b

First use the command to view the numbers of all breakpoints

info b

Then determine the number of the breakpoint based on the line number of the break you want to delete, and then use the command to delete the breakpoint.

d breakpoint number

Note: The number of breakpoints in a gdb debugging cycle is always incremented by 1 and will not decrease as the breakpoint is deleted

At the same time, at the breakpoint in gdb, when exiting and reentering, all the previously hit breakpoints will disappear. The breakpoint number will also be updated to 0.

2.8 Enabling and disabling breakpoints

Note: No matter whether you enable or disable breakpoints, breakpoints always exist, but the effect when disabling breakpoints is the same as without breakpoints.

Disable breakpoint instructions:

disable breakpoint number


Enable breakpoint instructions:

 enable breakpoint number

2.9 Go statement by statement after encountering a breakpoint

The debugging here is the same as that of vs. Go statement by statement. When you encounter a function, you will enter the function.

instruction:

step
step can be abbreviated as s

2.10 Step by step after encountering a breakpoint

The debugging here is the same as that of vs. Go step by step. When you encounter a function, you will not enter the function, but directly complete the function and go to the next line of code.

next
next can be abbreviated as n

2.11 View the value of variables during debugging

instruction:

p variable name

But we saw from the way that when we operate again, the value of the variable will no longer be displayed, so how can we make the value of the variable always displayed?

Command:

display variable name

When we don’t want to see the cancellation display:

instruction:

undisplay always displays the number

2.12 Jump to the specified location

When we debug the code, we may be in a loop again, but when we are sure that the loop is error-free, we want to jump out of the loop until we know the number of lines:

instruction:

until line number

2.13 Running the current function is completed

Applicable situation: debug into a function, make sure there is no error in the function, and jump out of the function directly

instruction:

finish

2.14 Run directly from one breakpoint to the next

instruction:

continue
continue can be abbreviated as c

2.15 call stack

instruction:

bt

2.16 Changing the value of variables during debugging

instruction:

set var variable name = the value you want to change to