Brief Analysis of Application Debugging Principles

1. Bugs and Debugging

Speaking of "Debug", we have to mention "Bug", a word familiar to programmers and gamers. It was first proposed by Dr. Grace Heber of the United States. At that time, the Harvard Mark II computer running research data suddenly stopped working properly. After repeated investigations by Heber and her team, they found that a moth flew into the internal relay of the computer and caused a short circuit. After repairing the fault, Heber humorously recorded the incident in her diary (Figure 1). The word "Bug" (originally meaning "bug") has gradually been widely used to describe hidden errors in computer programs. At the same time, inspired by the expulsion of moths and bugs from computers, the computer term "Debug" began to be used.

Figure 1

Debugging covers the entire computer field, including but not limited to digital circuits, analog simulation, embedded hardware and software, and application software. It is an important skill that technical R&D personnel must master. It has a significant impact on code error correction and product quality control during the product development process. This article mainly discusses and analyzes the software program debugging principles of mainstream hardware platforms and operating systems.

2. Debugging Principles - Breakpoints

For executable programs compiled and run in C and C++, debug breakpoint debugging requires support from hardware and operating system, which mainly depends on the following two points:

(1) The hardware platform and operating system provide methods for setting breakpoints.

(2) The breakpoint triggers a system interrupt notification to the debugger.

The implementation of the first breakpoint is divided into software breakpoints and hardware breakpoints from the perspective of computer system. Software breakpoints are implemented by inserting dedicated breakpoint instructions (insertion stubs) into the specified code location. Hardware breakpoints are implemented by directly using the debug registers of the CPU core. This scenario is mainly for ROM read-only memory that does not allow write operations and situations that cannot be handled by software breakpoints, such as the interrupt vector table being destroyed.

Figure 2

Different hardware architectures have different breakpoint implementation instructions. If our hardware processor is based on the X86 series, the working principle of its software breakpoint is that the debugger saves the first byte of the original instruction at the corresponding position of the code, and then writes an INT3 instruction (Figure 2). Because the binary code of the INT3 instruction is 11001100b (0xCC), which is only one byte, only one byte needs to be saved and restored when setting and canceling the breakpoint. When the CPU executes the INT3 instruction, it will trigger the operating system soft interrupt and stop running the current process, and execute the interrupt processing function defined by the kernel instead. The X86 hardware breakpoint uses the DR0-DR7 debug address registers, but due to the limited number of registers for storing breakpoint addresses (DR0-DR3), only 4 breakpoints can be set. The breakpoint implementation based on the ARM series is similar to that of the X86 platform. The working principle of software breakpoints is to replace instructions with the opcode of the HLT or BRK instruction. Hardware breakpoints use the comparator built into the core and stop execution and trigger the corresponding interrupt when the execution reaches the specified address. Like X86, there is a limit on the number of breakpoint settings due to the limited number of hardware breakpoint units provided.

Regarding the second point, the interrupt notification of the operating system, taking the X86 platform as an example, the corresponding function triggered by the operating system soft interrupt on the Windows platform is KiTrap03(), and on the Linux platform it is the do_int3() function. These functions are interrupt handling routines pre-defined by the operating system kernel. KiTrap03() will distribute the breakpoint exception to the user mode debugger in the form of a debug event through the debugging subsystem, and wait for the debugger's reply. Only after the debugger confirms that the exception is a breakpoint set by "itself" will it allow the debugged process to be suspended for interactive debugging. The do_int3() routine sends a SIGTRAP signal to the debugged process. When the process receives the SIGTRAP signal, the current process gives up the CPU and suspends its operation.

3. Debugging Principles - Process Interaction Model

If the debugger and the debugged process are located on the same physical machine, it is cross-process debugging. Otherwise, it is remote debugging. Remote debugging adds a layer of network protocol interaction on top of cross-process debugging. Since there are some differences in the process description models of Windows and Linux, we will introduce the debugger process interaction principles of these two platforms respectively.

3.1 Windows

The WIN32 kernel provides a set of system APIs to support the interaction between the debugger and the debugged process. Here are a few important functions for introduction.

Figure 3

The debugger interaction based on WIN32 is realized by combining the debugging functions and a series of debugging events ^[1] shown above. After the debugger is started, it first creates the process to be debugged through the CreateProcess function, or binds it to the running process by calling the DebugActiveProcess function. After a series of preparation operations, it will enter the debugging loop phase. The debugger will block the call to the WaitForDebugEvent function to wait for the debugging event notification. When there is an event notification such as an exception event or a dll file loading and unloading event, this function returns immediately. The returned event information is encapsulated in the DEBUG_EVENT structure. This structure contains the event type, related process description information and file handle, etc. At this time, the debugger enters the command interaction phase. The debugger will match the event in the custom event processing function ProcessEvent and execute the callback code of the corresponding event. If this type of operation is triggered by a breakpoint, all threads of the debugged target process will be suspended by the operating system. At this time, the debugger can call related functions such as GetThreadContext to obtain the context information of the specified thread. The debugging information interaction between the debugger and the target process is based on the Windows inter-process synchronization mechanism. For related information, please refer to the relevant Microsoft development documents ^[2] .

Figure 4

3.2 Linux

Compared with Windows, Linux as an open source system can peek deeper into the debugger principle through the source code. Here we take GDB debugging as an example.

When we use GDB command debugging on a compiled C program file from the shell terminal, the system will first create a GDB process (debugger process), which will fork a child process (debugging target process). After the child process is initialized, it will first call the key system function ptrace (PTRACE_TRACEME...) to put itself into the traced mode; at the same time, it will call the execv function to execute the C program file to be debugged, which will pause the current process and send a SIGCHLD signal to the parent process. After receiving the SIGCHLD signal, the parent process can debug the debugged process. GDB also supports debugging existing processes. At this time, the GDB process will call ptrace (PTRACE_ATTACH, pid, ...) to put the debugged process into the traced mode.

Figure 5

The ptrace system function ^[3] is the core dependency function of GDB interactive debugging. The first parameter of this function, request, determines the operation mode to be executed. These operation modes define the behavior of the debugger to control reading and writing the debugged process. The specific supported operation modes are as follows:

Figure 6

With the powerful function of ptrace, the GDB debugger process can read and write the instruction space, data space, stack and register values ​​of the debugged target process, such as stack printing, variable display modification, etc. GDB will also intercept almost all signals notified by the kernel to the debugged process. By intercepting and judging these signals, the debugger process can perform breakpoint matching and single-step debugging on the program ^[4] .

4. Future Development of Debuggers

Windbg on Windows and GDB on Linux are both comprehensive software tools with complex logic implementation. These debuggers are rooted in different hardware platforms and operating systems, and have significant differences in underlying functional implementation and interaction models. They are obviously not suitable for cross-platform development. With the rise of interpreted languages ​​such as Java, Js, and Python and the development of cloud platforms, virtual machine debugging systems (JDPA, v8 debug protocol) have been proposed and widely used. This flourishing situation has left IDE manufacturers with a very thorny problem - the huge development difficulty caused by the inconsistent debugger interaction specifications. Microsoft took the lead in proposing the DAP (Debug Adapter Protocol) protocol to address this problem, allowing IDEs from various manufacturers (mainly serving its own VsCode) to communicate with debuggers of different languages ​​through the same protocol based on the adapter mode, trying to shield the differences in the underlying hardware and software and reduce the difficulty of IDE debugger development. The DAP protocol has been recognized by the industry for its professionalism and universality, but JAVA editors such as Eclipse and IDEA are still directly adapted to the JDPA debugging system. After all, the unified specifications of the software industry are still behind the competition for the right to speak in the industry among various technology companies.