Shulou(Shulou.com)05/31 Report--

How to analyze the use of gdb skills, in response to this problem, this article details the corresponding analysis and solution, hoping to help more small partners who want to solve this problem find a simpler and easier way.

01 Concept

GDB is a powerful command-line debugging tool for UNIX/LINUX operating systems published by GNU Open Source.

In practice, there are two debugging methods: online debugging and offline debugging.

Offline debugging is suitable for development and testing environment, you can start and stop the process freely, set breakpoints; online debugging is generally used for field problem analysis, you can not start and stop the process casually, and it has high technical requirements.

02 Prerequisites 2.1 Compilation

To perform gdb debugging, you need to add the compile debugging option-g to the Makefile, for example:

gdb dup_file.c -o dum_file_elf -g -lpthread

Note: The-g option is used to add source code information to the executable file (ELF), such as the number of machine instructions in the ELF corresponding to the number of lines of source code. But not the entire source file embedded in the executable file, so debugging must ensure that gdb can find the source file.

-g The complete format is-glevel, where level specifies how much debugging information is included in the debugging information. The default is 2,level=1 at least, level=3 at most.

2.2 readelf View segment information

For example:

readelf -S helloWorld|grep debug

Note: helloWorld is the file name. If there is no debug information, it cannot be debugged.

2.3 file View strip status

The following cases are also non-debuggable:

file helloWorld

helloWorld: (omitting previous content) striped

Note: If the last is striped, it means that the symbol table information and debugging information of the file have been removed, and gdb debugging cannot be used. But not striped does not mean it can be debugged.

03 Use Method 3.1 Start Debugging

During development, you can copy the source code and executable files to a directory, use gdb to start the process for debugging, or you can mount them to the compilation environment without copying the source code and executable files, and use NFS to perform debugging; in the field environment, use ps to obtain the pid of the process, and then gdb -p pid to perform online debugging.

Offline debugging:

gdb process name

gdb -tui process name

Online debugging:

ps -A |grep process name

gdb -p pid/gdb attach pid

Note: Use the-tui parameter to divide the debugging window into two parts: the source code above, the debugging information below, and use Ctrl+n/Ctrl+p or the arrow keys to turn pages.

Debugging with parameters:

1. Bring parameters when starting

gdb --args xxx parameter

2. Run with parameters after startup

# gdb xxx

(gdb)run parameter

3. Set args after startup

# gdb xxx

(gdb)set args parameter

core file debugging

When the program core dumps, it may produce a core file, which can be a large program to help us locate the problem. But that's assuming the system doesn't restrict the creation of core files. You can use the command limit -c to see:

$ ulimit -c

If the result is 0, there will be no core file left even if the program core dumps. We need to make the core file capable of producing:

ulimit -c unlimited #Indicates unlimited core file size

ulimit -c 10 #Set the maximum size in blocks, 512 bytes by default

You can choose one of the above two ways. The first is unlimited, and the second specifies the maximum generated size.

For debugging the generated core file, online loading and offline loading can be used, as follows:

gdb executable core file

3.2 SET command

Note: Sometimes the debugging information printed using p is incomplete or not easy to read, you can use set print elelent 0 and set print pretty on settings.

3.3 handle command

handle command

handle SIGUSR1 nostop noprint

handle SIGUSR2 nostop noprint

handle SIGPIPE nostop noprint

handle SIGALARM nostop

handle SIGHUP nostop

handle SIGTERM nostop noprint

Note: Set relevant actions for signals during GDB debugging.

3.4 set breakpoints

Interrupting points is more skillful. Although there are many ways to interrupt points, the following are generally used in actual debugging:

function break point: b function name

line break point: b source file: line number

conditional breakpoint:

break breakpoint if condition

continue Breakpoint number (once executed means set, again executed means cancel)

continue Breakpoint Number Condition

Note: Conditional breakpoints are very useful. In actual debugging, it is often necessary to debug the function call relationship under specific scenarios. In this case, it is necessary to set the conditions for breakpoint triggering.

View Breakpoints: info breakpoint/info break/info b

Delete Breakpoints: delete breakpoint number/delete(delete all breakpoints)

Disable/enable breakpoint: disable/enable breakpoint

ignore：

A special use of breakpoint conditions is where the program stops only after reaching the breakpoint a certain number of times, using the instruction:

ignore breakpoint number

ignore 2 10 The breakpoint will not stop until it is triggered 10 times, and the count will automatically decrease by 1 each time the breakpoint is triggered.

Description: After breaking the breakpoint, is it possible to execute continue and wait for the breakpoint to run? Not necessarily. Sometimes the execution of code at breakpoint needs external departure. For example, the web can trigger execution only after sending a specific message. If you wait for no message to depart and never execute at breakpoint, you need to manually set the departure condition in combination with your own business logic.

3.5 executing program

There are two ways to execute a program: one is to perform step-by-step analysis starting with the main function, and the other is to execute to the breakpoint.

Rerun: r/run

Continue: c/continue

Step: n/next/next N(execute N times next)

Step into: step(enter the function when encountering a function, use finish when exiting the function)

End function: finish

Forced return: return(ignore the currently unexecuted part, forced return)

3.6 display stack

(gbd) backstrace/bt

Sometimes the number of jumps is too many, do not know the specific hierarchy of the call, you can use bt to view the stack, the command will produce a list, containing the running process and related parameters.

3.7 variable operation

Set variable: set variable = expression

When debugging, sometimes you need to set some false data to view the corresponding output, such as viewing the process execution according to Boolean values. In this case, you need to manually set the data value when executing to the specified position.

Monitoring variables:

watch variable (pause when value changes)

watch (pause when accessed or changed)

rwatch (pause when accessed)

Sometimes we need to observe how a variable changes, such as how a global variable is initialized and how it is called, which requires using watch to monitor variables.

Variable type:

ptype var Variable type

whatis var displays the type of a variable var

Print variables/expressions:

Print variables: p variables

Print character/expression: p "%s", character/expression

Format output: p/format control character print content

Description:

GDB can support variable display formats:

x: Display variables in hexadecimal format

d: Display variables in decimal format

u: Display unsigned integers in hexadecimal format

o: Display variables in octal format

t: Display variables in binary format

c: Display variables in character format

f: Display variables in floating-point format

You can also use x (Examination) to print character information that needs to be displayed, in the following format:

x/Format Address

Format (optional) is usually NFU:

1. N represents the number of repetitions (indicating the length of the display memory, that is, the contents of several addresses are displayed backwards from the current one)

2. F indicates display format

3. U indicates unit (b: byte, h: half word [2 bytes], w: word [4 bytes, default], g: double word [8 bytes]). Indicates how many bytes are fetched as a value. If not specified, GDB defaults to 1 byte. When we specify the byte length, GDB will read the specified byte from the specified memory address and fetch it as a value.

The parameter u can be replaced with the following characters:

b: indicates a single byte

h: double byte

w: four bytes

g: indicates eight-character section

3.8 debug function

disassemble

You can use the disassembly instruction to discover exactly what happened in the function, as follows:

1、disassemble

2. Disassemble program counter

Disassemble Start Address End Address

Format 1 represents the entire current function of disassembly, format 2 represents the entire function of the function where the disassembly counter is located, and format 3 represents the portion of disassembly from the start address to the end address.

call

Forced call function: call expression

3.9 exit debug

q/quit

After execution reaches the breakpoint, exit with the q/quit instruction.

04 Multiprocess Debugging 4.1 Configuration

detach-on-fork

This property determines whether gdb debugs both parent and child processes, or separates child processes after forking them.

on: child process (or parent process, depending on which process gdb debugs initially, i.e. the value of follow-fork-mode)

off: Debug parent-child processes simultaneously, one in a debugged state while the other is suspended by gdb

Set Detach-on-fork on/off

follow-fork-mode

This attribute determines the behavior of gdb after a process calls fork.

set follow-fork-mode parent: By default, gdb chooses to follow (i.e. debug) the parent process after invoking fork, while the child process is running (the parent process is blocked).

set follow-fork-mode child: gdb chooses to debug the child process after fork, while the parent process is running.

4.2 viewing process

View current debugging progress: info advisors

05 Multithreaded Debugging 5.1 View Threads

View threads: info threads

Note: "*" in front of the output information indicates the current thread of debugging (generally thread switch thread after viewing).

Some programs create multiple child threads in the main thread during execution, so the number of threads displayed by info threads before and after execution changes dynamically.

5.2 View thread stack

View all thread stacks: thread apply all bt

View the specified thread stack: thread apply thread1 thread2... bt

5.3 switch threads

Switch threads: thread N

Note: By printing counter, you can see that multiple threads are running. If you want to keep other threads in a stopped state, only the current debugging thread can be executed.

5.4 blocking threads

Block other threads, debug only current thread work:

set scheduler-locking [on|off|step]

Run specified threads and allow other threads to execute in parallel:

thread apply N command

About how to analyze the use of gdb skills to share the answer to the question here, I hope the above content can be of some help to everyone, if you still have a lot of doubts not solved, you can pay attention to the industry information channel to learn more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.