Analysis of problems when using GDB and QEMU to debug the kernel

Article Title: Analysis of issues when using GDB and QEMU to debug the kernel. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source. QEMU + GDB can be used for source code-level kernel debugging. However, there is a problem-when the 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). Note that
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 stopped, the interruption cannot be triggered. After receiving the s command, the virtual CPU starts to execute the command. At this time, such
If the kernel permits interruption, the virtual clock will trigger the interruption. Therefore, after the s command executes an instruction, it stops at the beginning of the clock interrupt processing program, rather than the next instruction in the desired function.

Now let's take a look at the solution. In my opinion, we need to modify the semantics of the single-step command when gdb remotely debugs the kernel. There are two directions.

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.

Among the two methods, I think 1 is better and the implementation is clear and clear, but I need to be familiar with the gdb code. 2 The method is complex, especially when the current command is a jump command, it is not easy to determine the location of a temporary breakpoint.

In addition, we can only use tbreak + offset to replace the n and s commands as a temporary privilege.