دانلود کتاب ساختن دیباگر

It all started with a moth. In 1947, a team at Harvard University was working on the Harvard Mark II electromechanical computer. This large machine weighed over 20 metric tons and occupied more than 370m2 of floor space. On September 9, the team was diagnosing an issue with the Mark II and traced it back to a rather unusual source; a moth had gotten stuck in one of the electromagnetic relays on which the machine was based, causing it to malfunction. After they removed the minibeast, they taped it to a log book with the phrase “First actual case of a bug being found.” While computer scientists used the term “bug” before this incident, the poor moth’s demise contributed to its widespread use in the lexicon. Most of the time, however, we’re not looking for actual bugs in our systems, so we don’t require a screwdriver and magnifying glass to identify issues. Instead, we need a program that can trace, manipulate, and visualize the state of a different program running on our system. Such a program is called a debugger. Developers typically use debuggers for tasks such as tracing the control flow of their code as it runs, inspecting the values of variables at various points of execution, halting the program at pre-determined locations, and executing functions inside the running process. In this book, we’re particularly concerned with debuggers for compiled code that runs directly on your central processing unit (CPU), written in a language like C, C++, Rust, or FORTRAN. Debuggers for these programs need to interface directly with the operating system and the underlying hardware, which can lead us to some deep insights into how computers actually work. Over the course of this book, we’ll build a command line debugger for native code. I’ll call the debugger sdb, for Sy’s Debugger, but you can call yours whatever you like. (You might want to avoid conflicting with existing debuggers like GDB and LLDB, however.) When we begin, the project will consist of a single executable, sdb, which the user can interact with on the command line. As we progress, we’ll build the majority of the debugger as a library, libsdb, then author a command line driver that uses its functionality. This design will make it easier to write automated tests for the code and enable you to develop applications that interact with the debugger programmatically.