Linux GDB multi-thread debugging

Linux GDB multi-thread independent debugging thread

Http://coolshell.cn/articles/3643.html

I. multi-thread debugging

Multi-threaded debugging may be the most frequently asked. In fact, the following commands are important:

Info thread to view the thread of the current process. Thread <ID> switch the debugging thread to the thread with the specified ID. Break file. C: 100 thread all sets breakpoints for all threads passing through the file. c file 100th line. Set scheduler-locking off | on | step, which is the most frequently asked. When you use the step or continue command to debug the currently debugged thread, other threads are also executed at the same time. How can we only execute the program to be debugged? You can use this command to achieve this requirement. Off does not lock any thread, that is, all threads are executed. This is the default value.
On is executed only by the currently debugged program. Step in a single step, except for the next function (people familiar with the situation may know that this is actually an action to set the breakpoint and then continue, only the current thread will execute. Ii. debugging macros

There are many problems. In GDB, we cannot define the print macro because the macro is pre-compiled. However, we still have a way to debug macros. This requires the cooperation of GCC.

Add-Ggdb3In this way, you can debug the macro.

In addition, you can use the following GDB macro debugging command to view related macros.

Info macro-you can view the files in which the macro is referenced and what the macro definition is. Macro-you can view the macro display.

Iii. source files

This is also a lot of questions, too many friends said they could not find the source file. Here I would like to remind you to do the following checks:

Whether the compile programmer has added the-G parameter to include the debug information. Whether the path is set correctly. Use the directory command of GDB to set the directory of the source file.

The following is an example of debugging/bin/LS (in Ubuntu)

1234567891011121314151617181920 $ apt-Get sourcecoreutils $ sudoapt-Get installcoreutils-dbgsym $ GDB/bin/lsgnu GDB (GDB) 7.1-ubuntu (GDB) List main1192 ls. c: No such fileor directory. INLS. C (GDB) directory ~ // Src/coreutils-7.4/src/source Directories
Searched:/home/hchen/src/coreutils-7.4: $ cdir: $ CWD (GDB) List main1192} 1193} 11941195 int1196 main (INT argc, char ** argv) 1197 {1198 int I; 1199 struct pending * thispend; 1200 int n_files; 1201

Iv. Conditional breakpoint

The conditional breakpoint syntax is: break [where] If [condition], which is very useful. Especially in a loop or recursion, or to monitor a variable. Note that this setting is in GDB, but every time it passes through that breakpoint, GDB will help you check whether the conditions are met.

V. Command Line Parameters

Sometimes, the program we need to debug requires command line parameters, and many friends do not know how to set the command line parameters of the program to be debugged. In fact, there are two methods:

The-ARGs parameter set ARGs command in the gdb environment of the gdb command line. Vi. GDB Variables

Sometimes, when debugging a program, we can not only view the runtime variables, but also directly set the variables in the program to simulate some situations that are difficult to test, compare some errors or switch branch statements. You can use the set command to modify the variables in the program.

In addition, do you know that GDB can also contain variables? Just like shell, variables in GDB start with $. For example, if you want to print all elements in an array, you can:

12345 (GDB) set $ I = 0 (GDB) p a [$ I ++]... # Then press Enter.

Of course, here is just an example to show that the program variables and GDB variables can interact.

7. x commands

Maybe you like to use the p command. Therefore, when you do not know the variable name, you may be confused, because the p command always requires a variable name. The X command is used to view the memory. In GDB, you can view the help of "help X.

X/x outputs x/d in hexadecimal notation x/C output in decimal notation x/C output in single-character x/I disassembly-normally, we will use the X/10i $ ip-20 to view the current Assembly ($ IP is the instruction register) x/s to output string 8, command

Some friends asked me how to automate debugging. Here we will introduce the command. For a simple understanding, it is to package a group of gdb commands, a bit like the "macro" of the word processing software ". The following is an example:

12345678910 (GDB) breakfuncbreakpoint 1 at 0x3475678: filetest. c, line 12. (GDB) command1type commands forwhen breakpoint 1 is hit, one per line. end with a line saying just "end".> print arg1> Print arg2> Print arg3> end (GDB)

When our breakpoint arrives, we automatically execute the three commands in the command to open the three parameter values of func.

(Full text)

Http://blog.csdn.net/maintyb011/archive/2010/07/22/5755723.aspx

Set the Core Environment
Uname-a view Machine Parameters
Ulimit-a view default parameters
Ulimit-C 1024 sets the core file size to 1024
Ulimit-C unlimit: Set the core file size to unlimited.

Multi-thread dump is often a segment error, which generally involves illegal memory read/write. You can use the following command to enable the system switch so that it can generate
Core File.
Ulimit-C Unlimited

Thread debugging command
(GDB) info threads
Display All the currently debuggable threads. Each thread has an ID allocated to it by GDB, which will be used in subsequent thread operations.
There are * threads currently being debugged.

(GDB) thread ID
Switch the thread of the current debugging to the thread with the specified ID.

(GDB) thread apply id1 Id2 command
Let one or more threads execute the gdb command.
(GDB) thread apply all command
Let all the debugging threads execute the gdb command.

(GDB) set scheduler-locking off | on | step
It is estimated that all users who have used multi-thread debugging can find that when using the step or continue command to debug the currently debugged thread, other threads also execute at the same time, how can I only execute the program to be debugged? You can use this command to achieve this requirement.
Off does not lock any thread, that is, all threads are executed. This is the default value.
On is executed only by the currently debugged program.
Step in a single step, except for the next function (people familiar with the situation may know that this is actually an action to set the breakpoint and then continue, only the current thread will execute.

// Display thread stack information
(GDB) BT
View All call stacks

(GDB) F 3
Call box level

(GDB) I locals
Display all variables of all current call stacks

# GNU/Linux/Unix open-source platform supplement: Linux viewing thread CPU usage command ps h-EO user, PID, ppid, tid, time, % CPU, CMD -- Sort = % CPU
A lot of information prompts that the upper-case h, that is, Shift + H, can be displayed after the top, but the test does not work.