[Goto] How GDB works in general

Transferred from: http://www.spongeliu.com/linux/howgdbwork/

Or a M, the interviewer asked me: "Have you used gdb?" "A:" used, adjusted two years of the bug. "Well, explain to me how GDB works?" Or is it related to what's in the kernel? ”。

Yes, gdb Why can I debug a program? Why is it possible to take over the operation of a program? I've thought about it before, but I forgot to check it later on. I thought of our binary translator and thought of Intel's Pin,dynamo. These are the translated code into the Codecache to run, and then take over the execution of the entire program. is gdb the same?

If this is the case, why do I remember to run a program with GDB, and this program will have a separate process? How is GDB's attach function implemented?

Thinking about it, I still didn't answer it. The interview is made up of a small cup with such a detail and a final collection into a large cup.

So, what exactly is gdb taking over the execution of a process? In fact, very simply, through a system call: Ptrace. The prototype for the Ptrace system call is as follows:

#includeLong Ptrace(Enum __ptrace_request Request, pid_t PID,void*addr,void*data);

> Description: The Ptrace system call provides a way for the parent process to observe and control the execution of other processes, examine and alter its core image, and register. It is mainly used to implement breakpoint debugging and system call tracing. (Man manual)

In fact, when it comes to this, all the principle level should be more clear (and do not go to the core of how to achieve ptrace). GDB calls this system call and then controls the execution of other processes with some parameters.

Let's look at some of the main options for the request parameter in the Ptrace function:

ptrace_traceme:  indicates that the process will be tracked by its parent process and delivered to all signals of the process, even if the signal is ignored (except for Sigkill), it will be stopped, and the parent process will be informed of the situation through wait ().

> What does that mean? We can combine it to look at GDB. If you run a program in GDB, first gdb will fork a child process, then the child process calls the Ptrace system call, the parameter is Ptrace_traceme, and then call an exec execution program. The basic process is this way, and there may be discrepancies in the details. It should be noted that This option ptrace_traceme is called by the child process, not the parent process!

ptrace_attach:attach to a specified process so that it becomes a child of the current process trace, and the child process behaves as if it had performed a ptrace_traceme operation. However, it is important to note that although the current process becomes the parent process of the tracked process, the child process using getppid () will still be the PID of its original parent process.

ptrace_cont: The child process that was stopped before continuing to run. The specified signal can be delivered to the child process at the same time.

> This option is actually equivalent to the Continue command in GDB. When you use the Continue command, a process that is stopped by GDB can continue to execute, and if there is a signal, the signal is also delivered to the child process.

man ptrace

In fact, after a debug relationship is established using a ptrace system call with a parameter of Ptrace_traceme or Ptrace_attach, any signal delivered to the target program (except for Sigkill) will be intercepted by GDB. Or be intercepted by gdbserver in remote debugging and notify GDB. GDB therefore has the opportunity to process the signal accordingly and, depending on the properties of the signal, determines whether the previously intercepted signal is actually delivered to the target program when the target program continues to run.

Reference: The basic workings of GDB
"GdB Pocket Reference"

[Go] gdb works in basic