Linux Kernel analysis uses GDB and QEMU for debugging

Linux Kernel analysis uses GDB and QEMU for debugging-Linux general technology-Linux programming and kernel information. The following is a detailed description. During Linux Kernel Analysis, QEMU and GDB can be used for debugging. Although QEMU and GDB can implement source code-level kernel debugging, there is still a problem: when the Linux kernel allows interruption, a single-step command (n and s) will interrupt the clock. By browsing the source code of QEMU, we can find out the cause. The single-step command (n and s) in the gdb remote debugging communication protocol is s (see info gdb). The qemu gdb stub enters the single-step status of the virtual CPU after receiving the s command, however, before receiving the s command, qemu's virtual CPU stops (waiting for the gdb command ). At this time, the virtual clock has not been stopped. Therefore, it is very likely that the clock interruption will be triggered before the qemu virtual CPU starts, but the virtual CPU is still in the stopped status, the interruption cannot be triggered. After receiving the s command, the virtual CPU starts to execute the command. If the kernel permits interruption, the virtual clock will trigger the interruption. Therefore, the s command executes an instruction and stops at the beginning of the clock interrupt processing program, instead of the next instruction in the desired function.

To solve this problem, you need to modify the semantics of the single-step command when gdb remotely debugs the kernel.

1. Modify it on gdb. When processing the user's n and s commands, instead of sending the s command in the Protocol, it is divided into two steps. First, determine the start position of the next command (or the start position of the command corresponding to the next source code ). It is easier to determine the location of some server commands in some assume that some server commands are fixed to a specific length, however, the architecture of variable-length commands such as x86 requires a little effort (you need to determine the length of the current command, etc ). Then assume that the address identified in step 1 is naddr. Now we can process it like processing the user's tbreak * naddr, and then send and continue to run the command c.

2. Modify the processing method of protocol command s on gdb stub of qemu. After receiving the s command, instead of letting the virtual CPU enter the single-step execution status, it determines that without interruption, the location of the next command (note that the processing of the current jump command is complicated), and then set a temporary breakpoint at this location, when the virtual CPU reaches this breakpoint, it is immediately canceled after it enters gdb stub.