GDB debug signal, multiple threads, multiple processes

Turn from: http://blog.csdn.net/yanook/article/details/6585648

GDB is very powerful, this article mainly introduces the use of GDB to debug signals, multiple processes, multithreading, specifically as follows:

(a) signal

GDB has the ability to process any kind of signal when you debug the program, and you can tell GDB which signal to process. You can request GDB to receive the signal you have specified, and immediately stop the running program for you to debug. You can use GDB's handle command to accomplish this function.

Handle <signal> <keywords...>
Define a signal processing in GDB. Signal <signal> can begin with a sig or not with a sig, and can be used to define a range (such as Sigio-sigkill) that handles signals from the sigio signal to the SIGKILL, including Sigio, Sigiot, Sigkill three signals), you can also use the keyword all to indicate all the signals to be processed. Once the program being debugged receives the signal, the running program is immediately stopped by GDB for debugging. The <keywords> can be one or more of the following keywords.

Nostop
When the program being debugged receives a signal, GDB does not stop the program, but it will make a message that tells you to receive the signal.
Stop
When the program being debugged receives a signal, GDB stops your program.
Print
When the program being debugged receives a signal, GDB displays a message.
Noprint
When the program that is being debugged receives a signal, GDB does not tell you the message that you receive the signal.
Pass
Noignore
When the program being debugged receives a signal, GDB does not process the signal. This means that GDB will give this signal to the debugger to process it.
NoPass
Ignore
When the program being debugged receives a signal, GDB does not let the debugger process the signal.

Info signals
Info handle
See what signals are being detected in GDB.

(ii) thread

If your program is multi-threaded, you can define whether your breakpoint is on all threads or on a particular thread. GDB can easily help you with this work.

Break <linespec> Thread <threadno>
Break <linespec> thread <threadno> If ...
LINESPEC Specifies the line number of the source program to which the breakpoint is set. THREADNO Specifies the ID of the thread, note that this ID is assigned by GDB, and you can view the thread information in the running program through the "Info Threads" command. If you don't specify
Thread <threadno> indicates that your breakpoint is located on all threads. You can also specify a breakpoint condition for a thread. Such as:

(gdb) Break frik.c:13 thread if Bartab > Lim

When your program is stopped by GDB, all the running threads will be stopped. This is convenient for you to view the overall situation of the running program. And when you run the recovery program, all the threads are also restored. That even if the main process is being debugged.

Threads have their own registers, and the runtime stack may also have private memory.
GDB provides the following features for debugging multithreaded processes:
* Automatically advertise new threads.
* \ thread threadno\, a command to switch between threads.
* \ "Info threads\", a command to query an existing thread.
* \ "thread apply [Threadno] [all] args\", a command to provide commands to the thread.
* Thread-related breakpoint settings.
Note: These features are not available in all GDB versions, and ultimately depends on whether the operating system supports it.
If your GDB does not support these commands, an error message is displayed:
(GDB) Info threads
(GDB) Thread 1
Thread ID 1 not known. Use the ' Info threads\ ' command to
The IDs of currently known threads.
The GDB thread-level debugging feature allows you to observe all the threads in your program's operation, but whenever
GDB control, there is always a "current" thread. The debug command works on the current process.
Once GdB discovers a new thread in your program, it automatically displays a system letter about the thread
Interest. Like what:
[New Process 27]
However, the format is related to the operating system.
For debugging purposes, GDB sets the thread number itself.
' Info threads\ '
Displays summary information for all threads in the process. GDB Displays in order:
1. Thread number (GDB settings)
2. The thread identification of the target system.
3. The current stack of this thread.
A thread with a front hit \ "*\" represents the current thread.
For example:
(GDB) Info threads
3 process thread 0x34e5 in Sigpause ()
2 process thread 0x34e5 in Sigpause ()
* 1 Process thread main (argc=1, ARGV=0X7FFFFFF8)
At threadtest.c:68
' Thread threadno\ '
The line Cheng the thread number to Threadno is the current thread. Command line argument Threadno is GDB-default
The thread number. You can use the \ Info threads\ command to view the thread number set up in GDB. GDB Displays the thread
System-defined identification number and thread-corresponding stack. Like what:

(GDB) Thread 2
[Switching to process thread 23]
0x34e5 in Sigpause ()
\ "The content after switching depends on your operating system's definition of the thread identity."

' thread apply [Threadno] [all] args\ '
This command lets you issue the same command \ "Args\" to more than one thread, and [Threadno] has the same meaning.
If you want to issue commands to all threads in your process use the [all] option.
Whenever GDB interrupts your program (because of a breakpoint or a signal), it automatically chooses the signal or
The thread on which the breakpoint occurs is the current thread. GDB will use a message in the format \ [switching to Systag]\
To report to you.

(iii) process

1. A method of attach the child process
Attach to the function of the running process, that is, attach <pid> command. So we can use this command to attach to the subprocess and then Debug.

The general step is 1. First, in the initial code of the subprocess to be debugged, add a special code that causes the child process to sleep and wait, and then run the program to be debugged
2. View the resulting subprocess pid with Ps-ef |grep
3. Then gdb boot, attach <pid> to the process after the code snippet set the breakpoint, you can debug the

eg.

PID = fork ();
if (PID <0) {
printf ("fork err\n");
Exit (-1);
else if (PID = = 0) {
/* in child */
Sleep (60); ------------------ (!)

int value = 10;

**********
}/**in parent****/

Execute a program (for example, Examp)
Examp &---Let Examp run backstage. (not run in the background can also);

Find Process ID:
Ps-ef

Run GDB:
Gdb
(gdb) Attach xxxxx---xxxxx ID for the child process obtained by using the PS command
(GDB) Stop---This is important, you need to pause that subprocess, and then set some breakpoints and some watch
(GDB) Break xx
Breakpoint 1 at 0x10808:file eg1.c, line 37.
(GDB) C
Continuing.

2. Debugging multiple processes using the Follow-fork-mode method
It is best to use GDB version 6.6 or above

The general procedure for debugging multiple processes using the Follow-fork-mode method is:
1. Start GDB
2 setting set Follow-fork-mode [child/parent] Use the child parameter if you want to debug the child, such as debugging parent using parent
3 Startup Program Files file./hello----------of course, the path name itself.
4.break Num-----------If the child process is debugged, NUM is the number of lines of child process code.
And one trick is to break fork, which is to set a breakpoint at the fork function,