GDB Debug Principle--ptrace system call

This article by the domineering Pineapple Original, reprint please indicate source: http://www.cnblogs.com/xsln/p/ptrace.html

All articles about GDB index please click here

Introduction:

1. GdB basically everyone is using, have you ever wondered what its implementation principle is? Why can it control program execution, interrupt, access memory, or even change the process directly?
2. When using GDB debugger, the process state of the program is "T", but it does not seem to receive the sigstop signal, then what is this "T"?

Traced back, we are today to study the Linux under this powerful system call: Ptrace ()

First, the process state of Linux is broadly divided into the following categories:

1. D (task_uninterruptible), non-disruptive sleep state.
2. R (task_running), in Process execution.
3. S (task_interruptible), an interruptible sleep state.
4. T (task_stopped), pause state.
5. T (task_traced), the process is traced.
6. W (task_paging), in the process paging, 2.6 or more versions of the kernel have been removed.
7. X (Task_dead–exit_dead), exit status, process is about to be destroyed.
8. Z (Task_dead–exit_zombie), exit status, process becomes zombie process.

(The above content comes from the PS command Manual manual, please see the original version ↓)

The above 5 is what we are going to discuss, the GDB debugger's T state, the program is tracked. (For other status of the process, please own Baidu).

Please see the ptrace system call manual ↓

Ptrace's prototype can be seen as:

Long Ptrace (enum __ptrace_request request, pid_t pid, void *addr, void *data);

The meanings of the 4 parameters are:

1. Enum __ptrace_request Request: Indicates the command to be executed by Ptrace.
2. pid_t PID: Indicates the process to be traced by the ptrace.
3. void *addr: Indicates the memory address to monitor.
4. void *data: Stores the data read or to be written.

The description is as follows:

The Ptrace () system call provides a method that enables a program (tracer) to observe and control the execution of another program (the tracked person) and to examine and change the memory and registers of the tracked person. It is mainly used to implement breakpoint debugging and tracking system calls.

The tracker first needs to be followed by the attach (the word really doesn't know how to translate ...). But programmers should all know @[email protected]). This behavior and subsequent operations are thread-Independent: In a multithreaded process, each thread can be attach by a separate (possibly different) tracker, or simply ignore it. Therefore, the tracked person is always "a thread", not a (possibly multithreaded) process. The method of using the Ptrace command is to send the following command to the Tracer program:

Ptrace (Ptrace_foo, PID, ...)

The PID is the thread number assigned by the Linux system.

When tracked, the tracked thread is stopped when the signal is received, even if the signal is ignored (except for Sigkill). The tracker receives a notification when a call to Waitpid (or other class wait system calls) returns a status value that contains the reason that the thread being traced stopped. When the tracked thread stops, the tracker can use multiple Ptrace requests to inspect and edit the tracked thread. The tracking program allows the tracked thread to continue running, selectively ignoring the sent signal (and even sending a completely different signal to the traced thread).

As you can see, Ptrace is indeed a powerful system call, and GDB is based on the ptrace system. The principle is to use the Ptrace system call to establish a tracking relationship between the debugged program and GDB. All signals sent to the debugged program (except Sigkill) are then intercepted by GDB, which, based on intercepted signals, looks at the corresponding memory address of the program being debugged and controls the program being debugged to continue running. GdB commonly used methods have breakpoint settings and single-step debugging, and then we will analyze how they are implemented.

1. Establish a debugging relationship:

There are 2 modes of debugging a program with GDB, including using GDB to start a program, and attach to an existing process. corresponding to the following 2 ways to establish debugging relationships:

1) Fork: Using Fork+execve to execute the program being tested, the child process calls PTRACE (Ptrace_traceme) before executing EXECVE, establishing a tracking relationship with the parent process (debugger).

2) Attach:debugger can call PTRACE (Ptrace_attach,pid,...) and establish a tracking relationship between processes with process number PID. That is, use Ptrace_attach to make yourself the parent process of the debugged program (as you can see with PS). The tracking relationship established with attach can call PTRACE (Ptrace_detach,pid,...) To relieve. Note the attach process when the permissions issue, such as a non-root permission of the process is not attach to a root process.

2. Breakpoint principle:

1) The implementation principle of the breakpoint, is to insert the breakpoint instruction at the specified position, when the debugged program runs to the breakpoint, produces the sigtrap signal. The signal is captured by GDB and a breakpoint hit is determined, when GDB determines that this sigtrap is a breakpoint hit will be transferred to wait for the user input for the next step, otherwise continue.

2) The setting of breakpoints: Setting breakpoints in a program is to save the original instruction for that location, and then write int 3 to that location. When executing to int 3, a soft interrupt occurs, and the kernel sends a SIGTRAP signal to the child process, which, of course, is forwarded to the parent process. Then replace the INT3 with the saved instruction and wait for the recovery to run.

3) Breakpoint hit judgment: GdB put all the breakpoint location in a linked list, hit judgment is the location of the current stop of the debugger and the list of breakpoint location to compare, see whether the breakpoint produced signal, or irrelevant signal.

4) Conditional Breakpoint judgment: the principle of the same 3), just restore the breakpoint at the command, then add a step to determine the condition. If the expression is true, the breakpoint is triggered. because it needs to be judged once, the performance is affected by the addition of conditional breakpoints, whether or not a conditional breakpoint is triggered . On the x86 platform, some hardware supports hardware breakpoints, does not insert an int 3 at a conditional breakpoint, but instead inserts an additional instruction that, when the program goes to this address, does not emit an int 3 signal, but rather first compares the contents of a particular register and an address, and then decides whether to send int 3. therefore, when the location of your breakpoint is frequently "passed" by the program, using hardware breakpoints as much as possible will help improve performance .

3. Single-Step tracking principle:

This is easiest because the PTRACE itself supports single-step functions, calling PTRACE (Ptrace_singlestep,pid,...) Can be, as explained:

GDB Debug Principle--ptrace system call