Remote Debugging Drive module with GDB

In the previous article I summed up the general GDB remote debugging kernel process, because the first use of KGDB is to debug their own drive module, so here I have to use the GDB remote debugging driver module to do a summary.

In fact, debugging the driver module and debugging the kernel process is exactly the same, but debugging the driver module is a very important place is the driver initialization debugging is difficult, I will explain the reasons below.

Through two days of groping, I feel that although gdb can remotely debug the kernel, because debugging the kernel is relative to the specificity of debugging a common program, many of the things you can do in debugging a common program are not done when debugging the kernel (such as looking at the value of a variable, such as jumping to a function, These are likely to fail when debugging the kernel. Let's talk about the general process of driver module debugging.

1, start the target machine

Here because we do not debug the kernel, so the kernel can be started directly running, do not need gdb to participate, of course, we can also add kgdbwait under Grub to enable the kernel to boot by the remote GDB control, if not added, to represent the direct start of the kernel.

2, Target machine open interrupt mode

Stty ispeed 115200 ospeed 115200-f/dev/ttys0

echo g >/proc/sysrq-trigger

3, remote GDB control

After the target machine opens the interrupt mode, the target machine all kernel program will be suspended, waits for the remote GDB debugging, this time we have not loaded to debug the drive module, but we may set the breakpoint, also may enter continue lets the target machine continue to run. Note If you want to debug the kernel initialization module, this time you can set the necessary breakpoints so that the kernel enters the interrupt when initializing the drive module.

Debugging Driver Initialization considerations: When the driver is initialized, because the driver is not fully loaded into the system, So we can't get information such as the kernel's. Text,.data, so we are unable to set the interrupt on the driver code at this time, the night has said first inserted into the kernel does not debug, wait until loaded into the, and then the. Text and other information recorded, and then restart the target machine, reboot and then load the driver before the use of these confidence add-sysm The Bol-file command is loaded into GDB, and then the breakpoint is set, and it's great to think about it, but I tried, and the final result was a complete breakpoint. So if you want to debug the initialization of the drive, we have to add a breakpoint on the kernel function involved in the drive initialization process, and then continue to run.

4, debugging after the initialization of the driver

After initialization, we first have to live where the driver code is in memory:

Cat/sys/modules/*/section/.text

Then load the driver symbol table in GDB

Add-sysmbol-file *.ko 0x (value of. Text)

At this point we can set the correct breakpoint on the driver code, and then do the normal debugging.

Here are some considerations for driving debugging:

1, can not set breakpoints on the driver code, there will be no access to address the at * problem

I spent a lot of time on this issue, and finally my problem is in some functions in front of the __devinit,__devexit,__init,_exit and other attributes, the meaning of these macros is not summed up here, the compiler will be the macro corresponding to the driver code optimized to the appropriate memory location, To reduce memory footprint and increase efficiency, causing the breakpoint to be set to fail, the solution is to remove these constraints from the driver code, which has no effect on the driver's running results.

The problem of 2,value optimized out

Some people say that in the compilation of the kernel of the makefile in the default O2 optimization to O0, so that the compiler does not optimize the kernel, but at night some people said that this is not feasible, the kernel of the compiler must be optimized, I here is not to make any changes, on this issue does not really matter, Because it's possible that we can't see the value of a variable in a function, but we can see it in another function, so this problem has no effect and it's a waste of time not thinking about recompiling the kernel without a problem.

Let's talk about debugging the initialization code for the driver module:
The above has said how to debug the initialization code of the driver module, but the above does not completely solve the problem, according to the previous practice, I when GDB started debugging, in the initialization code involved in the kernel of the original function set breakpoints, and then run, it does make the driver stop at the breakpoint, But the problem I had before was that when the kernel function was done, I could not go back to the kernel code I had written, but the following problem occurred:

The reason for this problem is that I did not load the driver's symbol table correctly, that is, the *.ko file. It is important to load the location of the *.ko file, so let's say a few words about how to load the *.ko file incorrectly:

* In just enter GDB loaded, at this time the module code has not been read into memory, which can not be set breakpoints, this is the most common occurrence.

* After the Sys_init_module function is loaded, I initially thought that the driver code would be read into memory after the Sys_init_module, but when loaded after the function, it also encountered a situation where the breakpoint could not be set.

* Load the *.ko file into the wrong memory area, and you must load the *.ko file before probe or other initialization functions to debug the initialization code. However, if the memory address of the last loaded *.ko file is not the same as the. Text address after the driver module is actually loaded, the problem with cannot access memory at addresses is present:

So, from the above, you can see when loading the *.ko file is not important, it is important to load the location, as well as the time to set breakpoints. For the loaded location, we know that after the system first loads the drive module,. The text value is always the same, so we can write down the value of the. text when we first load the drive module, then reboot, reboot, open GDB, and load our *.ko file according to the previous. Text values. This will guarantee the consistency of the address.

As for the timing of setting breakpoints, it is important to set breakpoints on the driver code, you have to wait until the driver code is loaded into memory to set, because I write the driver and PCIe, so I can now set a breakpoint on the __pci_register_driver function, This is a kernel function, so I can set breakpoints, and when the driver runs to __pci_register_driver, this time our own driver code must have been loaded into memory, so we can set a breakpoint on the driver code (b probe). This driver initialization code can be debugged from the probe function.