This is the first part in a series of articles on how debuggers work. I’m still not sure how many articles the series will contain and what topics it will cover, but I’m going to start with the basics. In this part
I’m going to present the main building block of a debugger’s implementation on Linux – the ptrace system call. All the code in this article is developed on a 32-bit Ubuntu machine. Note that the code is very much platform specific, although porting it to other platforms shouldn’t be too difficult. Motivation
To understand where we’re going, try to imagine what it takes for a debugger to do its work. A debugger can start some process and debug it, or attach itself to an existing process. It can single-step through the code, set breakpoints and run to them, examine variable values and stack traces. Many debuggers have advanced features such as executing expressions and calling functions in the debbugged process’s address space, and even changing the process’s code on-the-fly and watching the effects. Although modern debuggers are complex beasts [1], it’s surprising how simple is the foundation on which they are built. Debuggers start with only a few basic services provided by the operating system and the compiler/linker, all the rest is just a simple matter of programming. Linux debugging – ptrace
The Swiss army knife of Linux debuggers is the ptrace system call [2]. It’s a versatile and rather complex tool that allows one process to control the execution of another and to peek and poke at its innards [3]. ptrace can take a mid-sized book to explain fully, which is why I’m just going to focus on some of its practical uses in examples. Let’s dive right in.Stepping through the code of a process
I’m now going to develop an example of running a process in "traced" mode in which we’re going to single-step through its code – the machine code (assembly instructions) that’s executed by the CPU. I’ll show the example code in parts, explaining each, and in the end of the article you will find a link to download a complete C file that you can compile, execute and play with. Read more: Eli Bendersky's website
I’m going to present the main building block of a debugger’s implementation on Linux – the ptrace system call. All the code in this article is developed on a 32-bit Ubuntu machine. Note that the code is very much platform specific, although porting it to other platforms shouldn’t be too difficult. Motivation
To understand where we’re going, try to imagine what it takes for a debugger to do its work. A debugger can start some process and debug it, or attach itself to an existing process. It can single-step through the code, set breakpoints and run to them, examine variable values and stack traces. Many debuggers have advanced features such as executing expressions and calling functions in the debbugged process’s address space, and even changing the process’s code on-the-fly and watching the effects. Although modern debuggers are complex beasts [1], it’s surprising how simple is the foundation on which they are built. Debuggers start with only a few basic services provided by the operating system and the compiler/linker, all the rest is just a simple matter of programming. Linux debugging – ptrace
The Swiss army knife of Linux debuggers is the ptrace system call [2]. It’s a versatile and rather complex tool that allows one process to control the execution of another and to peek and poke at its innards [3]. ptrace can take a mid-sized book to explain fully, which is why I’m just going to focus on some of its practical uses in examples. Let’s dive right in.Stepping through the code of a process
I’m now going to develop an example of running a process in "traced" mode in which we’re going to single-step through its code – the machine code (assembly instructions) that’s executed by the CPU. I’ll show the example code in parts, explaining each, and in the end of the article you will find a link to download a complete C file that you can compile, execute and play with. Read more: Eli Bendersky's website
Posts
0 comments:
Post a Comment