1

I want to build my own debugger, from scratch, so I am trying to pick up some of the concepts behind it. First, I am starting easy, using the ptrace library. But even at this point I am having some issues, let me run through this code:

int main(int argc, char** argv)
{
    pid_t child_pid;

    if (argc < 2) {
        fprintf(stderr, "Expected a program name as argument\n");
        return -1;
    }

    child_pid = fork();
    if (child_pid == 0)
        run_target(argv[1]);
    else if (child_pid > 0)
        run_debugger(child_pid);
    else {
        perror("fork");
        return -1;
    }

    return 0;
}

this is nothing really special, I am creating a child process using fork() the next function is what really I cannot understand

void run_target(const char* programname)
{
    procmsg("target started. will run '%s'\n", programname);

    /* Allow tracing of this process */
    if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
        perror("ptrace");
        return;
    }

    /* Replace this process's image with the given program */
    execl(programname, programname, 0);
}

The last call is the issue. this call represents the concept of overlaying process image.I am not fully getting what is happening. This is what the author says:

I've highlighted the part that interests us in this example. Note that the very next thing run_target does after ptrace is invoke the program given to it as an argument with execl. This, as the highlighted part explains, causes the OS kernel to stop the process just before it begins executing the program in execl and send a signal to the parent.
To run the debugger basically the parent process must trace the child process, which acknowledges that it wants to be traced using PTRACEME. But I can’t figure out what that execl is doing. I can understand the purpose and the output but can’t figure out HOW. I consulted the man pages but could not wrap my head around this. I would appreciate if someone could give me a clear explanation of what’s going on with this execl function.
not_here_to_play
  • 148
  • 7
  • 1
    Does this answer your question? [Differences between fork and exec](https://stackoverflow.com/questions/1653340/differences-between-fork-and-exec) – Davis Herring Dec 19 '21 at 01:04

1 Answers1

1

I think you agree on this: the concept is that the debugger must debug program TARGET, that can only be debugged if it calls PTRACE_TRACEME.

Naturally, TARGET does not call ptrace with PTRACE_TRACEME argument in its source code. So, the debugger must do it for it.

Initially, the debugger forks. At this time we have two processes:

  1. Father: it calls run_debugger()
  2. Child: it calls run_target()

Child is a process that the debugger has control on it, therefore it can call ptrace with argument PTRACE_TRACEME (in run_target()). But this process is not TARGET.

Thus, next step is associating to child the "image" of TARGET (namely the program we want to debug). A process image is an executable file required while executing the program, and it's composed of the 4 classical segments:

  1. Code (text segment)
  2. Data
  3. Stack
  4. Heap

execl and friends belong to exec family, namely functions which replace the current process image with a new process image. execl differs from its friend execv for the way the arguments are passed to the best of my knowledge, but the concept is the same.

So, what you need to know is that:

exec replaces the currently running program by another program (i..e., TARGET) inside an EXISTING process.

The latter has called ptrace with argument PTRACE_TRACEME so the new program will not ignore the future ptrace calls made by the debugger.

If your question is the implementation details of exec systemcall, I have not a perfect knowledge for it, but I can give some suggestions:

  • Reading "The exec-like Functions" in the book "Understanding Linux Kernel"
  • Having a look to the source code (this question) directionates you to the source code of execve which is totally fine for you, same concept of execl.
  • If you want to create your own exec, this question can be useful as well.
MM92x
  • 548
  • 1
  • 4
  • 25