LINUX 3.5.4 Ptrace (series V) __linux

From the list1.c we can see that the subprocess actively requests to be tracked through Ptrace_traceme, but for a debugger it must be able to proactively track an arbitrary process rather than just debugging those processes that are actively required to be tracked. Next we use LIST2.C to analyze vaguely Ptrace_traceme's handling of the Exec series system calls

List2.c

#include "ptrace.h"
void Main ()
{
     int pid, status;
    if ((Pid=fork ()) ==0) {
      ptrace (ptrace_traceme,0,0,0);
      Execl ("/ROOT/CHILD2.O", "./child2.o", 0);
      printf ("exec failed...\n");
    }
    else{wait
      (&status);
      if (wifstopped (status)) {
        printf ("Child has stopped!\n");
        fprintf (stderr, "%s", Strsignal (Wstopsig (status));
      }
      Sleep (3);
      Ptrace (ptrace_cont,pid,0,0);
      Wait (&status);
    }

Child2.c

#include "ptrace.h"
void Main ()
{
   printf ("Child start...\n");
   Sleep (1);
   while (1)
     //printf ("hello!\n");

The results of the operation are as follows:

Next we analyze the output of the program:

When the child process invokes Ptrace_traceme, the child Process initiative request is tracked. The subprocess then continues to execute, and when the exec system call is performed, the kernel sends Sigtrap to the child process. At this point, the wait for the parent process is awakened, and the corresponding information is output. This includes the current state of the child process (Trace/breakpoint trap).

The parent process then sleeps for three seconds, invoking Ptrace_cont to wake the child process to continue execution. At this point the subprocess prints out the appropriate information: child start ...

Here we can also see that the printf statement followed by exec is not executed, stating that after the Exec system call, the subprocess executes its own code snippet.

To be Continued