Shulou(Shulou.com)06/01 Report--

This article mainly introduces the example analysis of kernel debugging in the Linux system, which has a certain reference value. Interested friends can refer to it. I hope you will gain a lot after reading this article.

Debugging is an indispensable link in the process of software development, and the problem of how to debug the kernel will inevitably be faced in the process of Linux kernel development. However, for the sake of ensuring the correctness of kernel code, the developers of Linux system are reluctant to add a debugger to the Linux kernel source code tree. They believe that debuggers in the kernel will mislead developers and introduce bad fixes [1]. Therefore, debugging the Linux kernel has always been a thorny problem for kernel programmers, and the hardship of debugging is a remarkable feature that distinguishes kernel-level development from user-level development.

Although there is a lack of an effective built-in method to debug the kernel, the Linux system has gradually formed some techniques to monitor kernel code and error tracking in the process of kernel development. At the same time, many patches emerge as the times require, which add kernel debugging support to the standard kernel. Although some of these patches are not approved by the official Linux organization, they are functional and powerful. When debugging kernel problems, it is useful to use these tools and methods to track kernel execution and look at its memory and data structures.

This article will first introduce some kernel code monitoring and error tracking techniques on the Linux kernel, which vary according to the required environment and usage, and then focus on the source code-level debugging methods of the three Linux kernels.

1. Debugging technology of kernel-level software in Linux system.

Printk () is the most commonly used technique when debugging kernel code. By adding the printk () debug call to a specific location in the kernel code, you can print the concerned information directly to the screen, so that you can observe the execution path of the program and the concerned variables, pointers and other information. The Linux kernel debugger (Linux kernel debugger,kdb) is a patch to the Linux kernel that provides a way to check kernel memory and data structures when the system is running. Oops, KDB in the article to master Linux debugging technology has a detailed introduction, you can refer to. Kprobes provides an interface that forcibly enters any kernel routine and collects information from the interrupt processor without interference. Using Kprobes, you can easily collect debugging information such as processor registers and global data structures, without frequently compiling and starting the Linux kernel. For specific usage, please refer to debugging the kernel using Kprobes.

The above describes the common techniques and methods for debugging and tracing the Linux kernel. Of course, the methods of kernel debugging and tracing are more than those mentioned above. A common feature of these debugging technologies is that they can not provide effective kernel debugging methods at the source code level, and some of them can only be called error tracking techniques, so these methods can only provide limited debugging capabilities. Three practical kernel debugging methods at the source code level are described below.

Go back to the top of the page

two。 Using KGDB to build Linux kernel debugging environment

Kgdb provides a mechanism to debug the Linux kernel using gdb. Using KGDB, you can set breakpoints, check variable values, and step through the running of the program in the kernel, just like debugging a normal application. Debugging with KGDB requires two machines, one as a development machine (Development Machine) and the other as a target machine (Target Machine). The two machines are connected through a serial port or an Ethernet port. The serial connection cable is a cable with RS-232 interface. The second pin (TXD) and the third pin (RXD) are cross-connected at both ends of the cable, and the seventh pin (grounding pin) is directly connected. During debugging, the kernel being debugged runs on the target machine, and the gdb debugger runs on the development machine.

Currently, kgdb releases debuggers that support several architectures such as i386, x86x64, 32-bit PPC, SPARC, and so on. For the download address of the kgdb patch, see Resources [4].

2.1Debug principle of kgdb

To install kgdb debugging environment, it is necessary to apply kgdb patch for Linux kernel. The function of gdb remote debugging realized by patch includes three main parts: command processing, trap processing and serial communication. The main purpose of the kgdb patch is to add a debug Stub to the Linux kernel. Debugging Stub is a small piece of code in the Linux kernel that provides an intermediary between the development machine running gdb and the kernel being debugged. Gdb communicates with debug stub through gdb serial protocol. Gdb serial protocol is a message-based ASCII code protocol, which contains a variety of debugging commands. When a breakpoint is set, kgdb is responsible for adding a trap instruction before the instruction to set the breakpoint, and when the breakpoint is executed, control is transferred to the debug stub. At this point, the task of debugging stub is to transfer the current environment to gdb using the remote serial communication protocol, and then receive commands from gdb. The gdb command tells stub what to do next, and when stub receives a command to continue, it will restore the running environment of the program and return control of CPU to the kernel.

2.2 installation and setup of Kgdb

Next, we will take the Linux 2.6.7 kernel as an example to introduce in detail the process of establishing the kgdb debugging environment.

2.2.1 hardware and software preparation

The following hardware and software configurations are taken from the system configuration of the author's experiments:

The version of the kgdb patch follows the following naming pattern: Linux-A-kgdb-B, where An is the kernel version number of Linux and B is the version number of kgdb. Take the kgdb patch used in the experiment as an example. The version of the linux kernel is linux-2.6.7 and the patch version is kgdb-2.2.

After the serial port line is physically connected, use the following command to test the serial port connection between the two machines. The stty command can set the serial port parameters:

Execute on the development machine:

Stty ispeed 115200 ospeed 115200-F / dev/ttyS0

Execute on the target machine:

Stty ispeed 115200 ospeed 115200-F / dev/ttyS0

Execute on the developement machine:

Echo hello > / dev/ttyS0

Execute on the target machine:

Cat / dev/ttyS0

If the serial port connection is fine, "hello" will be displayed on the screen of the target machine.

2.2.2 installation and configuration

Next we need to apply the kgdb patch to the Linux kernel, set kernel options, and compile the kernel. The information in this area is relatively few, and the author gives a detailed introduction here. The following work is carried out on the development machine (developement). Taking the test environment described above as an example, some specific steps may need to be changed in the actual environment:

I. configuration and compilation of kernel

[root@lisl tmp] # tar-jxvf linux-2.6.7.tar.bz2 [root@lisl tmp] # tar-jxvf linux-2.6.7-kgdb-2.2.tar.tar [root@lisl tmp] # cd inux-2.6.7

Please follow the instructions given by the file README in the directory fix pack to execute the patch for the corresponding architecture. Since the experiment was done on the i386 architecture, you only need to install the patches: core-lite.patch, i386-lite.patch, 8250.patch, eth.patch, core.patch, i386.patch. When applying patch files, follow the order specified by the series file in the kgdb package, otherwise it may cause unexpected problems. The eth.patch file is a patch that needs to be used when choosing the Ethernet port as the connection port for debugging.

The command to apply the patch is as follows:

[root@lisl tmp] # patch-p1 [*] KGDB: Thread analysis [*] KGDB: Console messages through gdb [root@lisl tmp] # make

Before compiling the kernel, please pay attention to the optimization options in Makefile under the Linux directory. The default Linux kernel is compiled at the optimization level of-O2. Below this optimization level, the compiler changes the execution order of some code in the kernel, so the program runs inconsistent with the code order when debugging. You can change the-O2 option in Makefile to-O, but do not remove-O, otherwise there will be problems with compilation. In order for the compiled kernel to have debugging information, note that you need to add the-g option when compiling the kernel.

However, the debug option is automatically turned on when the configuration system is selected with the "Kernel debugging- > Compile the kernel with debug info" option. In addition, when you select "kernel debugging with remote gdb", the configuration system will automatically turn on the "Compile the kernel with debug info" option.

After the kernel has been compiled, use the scp command to copy the relevant files to the target machine (of course, you can also use other networking tools, such as rcp).

[root@lisl tmp] # scp arch/i386/boot/bzImage root@192.168.6.13:/boot/vmlinuz-2.6.7-kgdb [root@lisl tmp] # scp System.map root@192.168.6.13:/boot/System.map-2.6.7-kgdb

If the system starts so that some of the required device drivers are not compiled into the kernel, you also need to do the following:

[root@lisl tmp] # mkinitrd / boot/initrd-2.6.7-kgdb 2.6.7 [root@lisl tmp] # scp initrd-2.6.7-kgdb root@192.168.6.13:/boot/ initrd-2.6.7-kgdb

Startup of II and kgdb

After copying the compiled kernel to the target machine, you need to configure the system bootstrap to add the kernel startup options. The following is a description of the kgdb kernel boot parameters:

As described in the table, the kernel boot parameters have been different from previous versions since kgdb 2.0. When using the grub bootstrapper, the kgdb parameter is directly used as the boot parameter of the kernel vmlinuz. A configuration example of the bootstrap is given below.

Title 2.6.7 kgdb root (hd0,0) kernel / boot/vmlinuz-2.6.7-kgdb ro root=/dev/hda1 kgdbwait kgdb8250=1,115200

When using lilo as the bootstrapper, you need to put the kgdb parameter in a statement decorated by append. The following is an example of a configuration when using lilo as a bootstrap.

Image=/boot/vmlinuz-2.6.7-kgdb label=kgdb read-only root=/dev/hda3 append= "gdb gdbttyS=1 gdbbaud=115200"

After saving the above configuration, restart the computer and choose to start the kernel with debugging information. After a short run, the kernel will stop before creating the init kernel thread, print out the following information, and wait for the developer to connect.

Waiting for connection from remote gdb...

Execute on the development machine:

Gdb file vmlinux set remotebaud 115200 target remote / dev/ttyS0

Vmlinux is a link to the compiled Linux kernel file under the source code directory. It is an uncompressed kernel file from which gdb programs get all kinds of symbolic address information.

In this way, a relationship is established with the kgdb debug interface on the target machine. Once the connection is established, debugging in Linux is no different from debugging ordinary applications. You can type ctrl+c to interrupt the execution of the target machine at any time to carry out specific debugging work.

In versions prior to kgdb 2.0, the executable file gdbstart was also generated in the arch/i386/kernel directory after the kernel was compiled. Copy the file to the / boot directory on the target machine, and use the command instead of changing the kernel startup configuration file:

[root@lisl boot] # gdbstart-s 115200-t / dev/ttyS0

The debugging relationship between the development machine and the target machine can be established after the KGDB kernel boot boot is completed.

2.2.3 debugging through a network interface

Kgdb also supports the use of an Ethernet interface as a connection port for the debugger. When you apply a fix pack to the Linux kernel, you need to apply the eth.patch patch file. When configuring the kernel, select the kgdb debug item in Kernel hacking, and configure the kgdb debug port as the Ethernet interface, for example:

[*] KGDB: kernel debugging with remote gdb Method for KGDB communication (KGDB: On ethernet)-> () KGDB: On generic serial port (8250) (X) KGDB: On ethernet

In addition, when using the eth0 network port as the debug port, the configuration of grub.list is as follows:

Title 2.6.7 kgdb root (hd0,0) kernel / boot/vmlinuz-2.6.7-kgdb ro root=/dev/hda1 kgdbwait kgdboe=@192.168. 5.13Universe 192.168. 6.13/

The other procedures are the same as when using the serial port as the connection port.

Note: although you can use the Ethernet port as the debugging port for kgdb, it is easier to use the serial port as the connection port, and the kgdb project team recommends using the serial port as the debugging port.

2.2.4 debugging method of module

The debugging of kernel loadable module has its particularity. Because the addresses of the segments in the kernel module are finally determined when the module is loaded into the kernel, the gdb of the development machine cannot get all kinds of symbolic address information. Therefore, one of the problems that need to be solved in using kgdb debugging module is that you need to obtain the final load address information of the loadable module in some way and add this information to the gdb environment.

I. the debugging method of kernel module in Linux 2.4kernel

In the Linux2.4.x kernel, you can use the insmod-m command to output module loading information, for example:

[root@lisl tmp] # insmod-m hello.ko > modaddr

View the module loading information file modaddr as follows:

.this 00000060 c88d8000 2 stories 2 .text 00000035 c88d8060 2 stories 2 .rodata 00000069 c88d80a0 2 stories 5. .data 00000000 c88d833c 2 stories 2. BSS 00000000 c88d833c 2 stories 2.

In this information, all we care about is the address of four segments: .text, .rodata, .data, .bss. Add the above address information to the gdb on the development machine so that you can test the functionality of the module.

(gdb) Add-symbol-file hello.o 0xc88d8060-s .data 0xc88d80a0-s .rodata 0xc88d80a0-s .bss 0x c88d833c

This method also has some shortcomings, it can not debug the module initialization code, because the module initialization code has already been executed. If you don't load the module, you can't get the insert address of the module, let alone set the breakpoint before the module initialization. The following alternative methods can be used for this debugging requirement.

Use the above method to get the address information loaded by the module on the target machine, and then unload the module with rmmod. Import the resulting module address information into the gdb environment on the development machine and set a breakpoint before the kernel code calls the initialization code. This way, when you insert the module again on the target machine, the code stops before performing module initialization, so you can debug the module initialization code using the gdb command.

Another way to debug the module initialization function is that when the kernel module is inserted, the kernel module mechanism will call the function sys_init_module (kernel/modle.c) to initialize the kernel module, which will call the initialization function of the inserted module. The program code snippet is as follows:

…… …… If (mod- > init! = NULL) ret = mod- > init ();. ……

Setting a breakpoint on this statement can also stop before performing module initialization.

II, kernel module debugging method in Linux 2.6.x kernel

Since Linux 2.6in the kernel, due to the change of the module-init-tools tool, the insmod command no longer supports the-m parameter and has to take other methods to obtain the address where the module is loaded into the kernel. By analyzing the ELF file format, we know that the meaning of each paragraph in the program is as follows:

.text (code snippet): an operation instruction used to store an executable file, that is, it is a mirror image of the executable program memory.

.data (data segment): the data segment is used to store initialized global variables in the executable file, that is, variables and global variables statically assigned by the program.

.bss (BSS segment): the BSS section contains uninitialized global variables in the program, and the bss segment is all zeroed in memory.

.rodata (read-only segment): this segment holds read-only data and constructs unwritable segments in the process image.

By placing a bit of code in the module initialization function, we can easily get the address where the module is loaded into memory.

…… Int bss_var; static int hello_init (void) {printk (KERN_ALERT "Text location .text (Code Segment):% p\ n", hello_init); static int data_var=0; printk (KERN_ALERT "Data Location .data (Data Segment):% p\ n", & data_var); printk (KERN_ALERT "BSS Location: .bss (BSS Segment):% p\ n", & bss_var); … } Module_init (hello_init)

Here, by adding a simple program to the module's initialization function, the module can print out the load address in the kernel when it is loaded. The address of the .rodata section can be obtained by executing the command readelf-e hello.ko to get the offset of the .rodata in the file and add the align of the segment.

In order to enable readers to debug the module better, the kgdb project has also released some script programs that can automatically detect the insertion of the module and automatically update the symbol information of the module in gdb. The working principles of these scripts are similar to those explained earlier. For more information, please refer to Resources [4].

2.2.5 hardware breakpoint

Kgdb provides support for hardware debug registers. There are three types of hardware breakpoints that can be set in kgdb: execute breakpoints (Execution Breakpoint), write breakpoints (Write Breakpoint), and access breakpoints (Access Breakpoint), but do not support Icano access. Currently, kgdb supports hardware breakpoints through macros, and up to 4 hardware breakpoints can be set. These macros are used as follows:

In some cases, the use of hardware breakpoints is very convenient for kernel debugging. For the definition of hardware breakpoints and specific instructions for use, see reference [4].

2.3.Constructing debugging environment in VMware

The kgdb debugging environment needs to use two microcomputers as the development machine and the target machine respectively. After using VMware, we can successfully build the kgdb debugging environment with only one computer. Take the environment under windows as an example, create two virtual machines, one as a development machine and one as a target machine.

2.3.1 Serial connection between virtual machines

There are two ways to connect a serial port in a virtual machine. One is to specify the serial port of the virtual machine to connect to the actual COM, for example, the development machine is connected to the COM1, the target computer is connected to the COM2, and then the two serial ports are connected through the serial port line. Another easier way is to support mapping serial ports to named pipes in higher versions of VMware, and mapping serial ports of two virtual machines to the same named pipe. For example, select the same named pipe\\.\ pipe\ com_1 in both virtual machines, specify the com port of the target machine as the server, and select the "The other end is a virtual machine" attribute; specify the COM port of the development machine as the client side, and also specify the "The other end is a virtual machine" attribute of the COM port. For the IO mode property, select the "Yield CPU on poll" check box on the target, but not the development machine. In this way, a virtual machine can be used to build a kgdb debugging environment without any additional hardware. It not only reduces the hardware requirements for debugging with kgdb, but also simplifies the process of establishing a debugging environment.

2.3.2 skills in using VMware

VMware virtual machines are resource-intensive, especially when using two virtual machines in Windows as above. Therefore, it is best to equip the system with more than 512m of memory, and each virtual machine allocates at least 128m of memory. Such hardware requirements are not too high for the current mainstream configuration of PC. For the sake of system performance, try to use the character interface for debugging in VMware. At the same time, the sshd service is enabled by default in the Linux system, so it is recommended to log in to Linux using SecureCRT to operate, so that you can have a better user interface.

2.3.3 using kgdb in virtual machines under Linux

For the case of using VMware virtual machine under Linux, the author has not done any practical exploration. In principle, as long as a virtual machine is created as a target machine under Linux, the work of the development machine can be carried out in the actual Linux environment, and the process of building a debugging environment is similar to the process described above. Because only one virtual machine needs to be created, using the virtual machine under Linux to build a kgdb debugging environment has low requirements for system performance. (vmware has launched a version under Linux.) you can also use other debugging tools on the development machine, such as the more powerful cgdb, the graphical interface DDD debugger, and so on, to facilitate kernel debugging.

2.4 some characteristics and shortcomings of kgdb

The biggest disadvantage of using kgdb as the kernel debugging environment is that the kgdb hardware environment is highly demanding, and two computers must be used as target and development machines, respectively. Although the method of using a virtual machine can build a debugging environment with only one PC, it also puts forward certain requirements for the performance of other aspects of the system, and increases the complexity of building the debugging environment. In addition, the compilation and configuration of the kgdb kernel is also complicated, which requires some skills. The author also took a lot of trouble to do it at that time. When the debugging process is over, you also need to remake the kernel to be released. Using kgdb does not allow full debugging, which means that kgdb cannot be used to debug the initial boot process of the system.

However, kgdb is a good kernel debugging tool, which can be used for comprehensive debugging of the kernel and even for debugging kernel interrupt handlers. With the help of some graphical development tools, debugging the kernel will be more convenient.

Go back to the top of the page

3. Using SkyEye to build Linux kernel debugging environment

SkyEye is an open source software project (OPenSource Software). The goal of the SkyEye project is to simulate common embedded computer systems on common Linux and Windows platforms. SkyEye implements an instruction-level hardware simulation platform, which can simulate a variety of embedded development boards and support a variety of CPU instruction sets. At the core of SkyEye is GNU's gdb project, which combines gdb and ARM Simulator very well. After adding the function of ARMulator, it can simulate the embedded development board, on which you can debug not only the hardware driver but also the operating system. At present, Skyeye project has been greatly promoted in the field of embedded system development.

3.1installation of SkyEye and compilation of μ cLinux kernel

3.1.1 installation of SkyEye

The installation of SkyEye is not the focus of this article, there are a lot of information about it. For more information about the installation and use of SkyEye, please refer to reference [11]. Because skyeye is mainly used in the field of embedded systems, μ cLinux system is often used on skyeye. Of course, it is possible to use Linux as a system running on skyeye. Since there is not much information about the compilation of μ cLinux 2.6 on skyeye, it is described in more detail below.

3.1.2 μ cLinux 2.6.x compilation

To debug the operating system kernel in SkyEye, you must first make the debugged kernel run correctly on the development board simulated by SkyEye. Therefore, correctly compiling the operating system kernel to be debugged and configuring SkyEye is the first step in kernel debugging. Next, we take SkyEye to simulate the development board based on Atmel AT91X40, and run μ cLinux 2.6 as an example to introduce the specific debugging method of SkyEye.

I. install the cross-compilation environment

Install the cross compiler first. Although the use of the tool chain arm-elf-tools-20040427.sh is described in some materials, due to the different handling of macros and links between arm-elf-xxx and arm-linux-xxx, experience has shown that using the arm-elf-xxx tool chain will lead to errors in the final stage of linking vmlinux. So the cross-compilation tool chain we use here is: arm-uclinux-tools-base-gcc3.4.0-20040713.sh. For the download address of the cross-compilation tool chain, see [6]. Note that the following steps are best performed with the root user.

[root@lisl tmp] # chmod + x arm-uclinux-tools-base-gcc3.4.0-20040713.sh [root@lisl tmp] #. / arm-uclinux-tools-base-gcc3.4.0-20040713.sh

After installing the cross-compiled tool chain, make sure that the tool chain installation path exists in the system PATH variable.

II, making μ cLinux kernel

One of the easiest ways to get the μ cLinux distribution package is to visit the uClinux.org site directly [7]. The kernel version released by this site may not be the latest, but you can find the latest μ cLinux patch and find a corresponding Linux kernel version to make the latest μ cLinux kernel. Here, you will use this method to make the latest μ cLinux kernel. Currently (at the time of writing this article), the latest version of the release package available is uClinux-dist.20041215.tar.gz.

Download uClinux-dist.20041215.tar.gz, the download address of the file can be found in [7].

Download linux-2.6.9-hsc0.patch.gz, the download address of the file can be found in [8].

Download linux-2.6.9.tar.bz2, the download address of the file can be found in [9].

Now we have the entire linux-2.6.9 source code, as well as the required kernel patches. Please prepare a directory with 2GB space to complete the following process of making a μ cLinux kernel.

[root@lisl tmp] # tar-jxvf uClinux-dist-20041215.tar.bz2 [root@lisl uClinux-dist] # tar-jxvf linux-2.6.9.tar.bz2 [root@lisl uClinux-dist] # gzip-dc linux-2.6.9-hsc0.patch.gz | patch-p0

Or use:

[root@lisl uClinux-dist] # gunzip linux-2.6.9-hsc0.patch.gz [root@lisl uClinux-dist] patch-p0

< linux-2.6.9-hsc0.patch 执行以上过程后，将在linux-2.6.9/arch目录下生成一个补丁目录－armnommu。删除原来μcLinux目录里的linux-2.6.x(即那个linux-2.6.9-uc0)，并将我们打好补丁的Linux内核目录更名为linux-2.6.x。 [root@lisl uClinux-dist]# rm -rf linux-2.6.x/ [root@lisl uClinux-dist]# mv linux-2.6.9 linux-2.6.x III、配置和编译μcLinux内核 因为只是出于调试μcLinux内核的目的，这里没有生成uClibc库文件及romfs.img文件。在发布μcLinux时，已经预置了某些常用嵌入式开发板的配置文件，因此这里直接使用这些配置文件，过程如下： [root@lisl uClinux-dist]# cd linux-2.6.x [root@lisl linux-2.6.x]#make ARCH=armnommu CROSS_COMPILE=arm-uclinux- atmel_ deconfig atmel_deconfig文件是μcLinux发布时提供的一个配置文件，存放于目录linux-2.6.x /arch/armnommu/configs/中。 [root@lisl linux-2.6.x]#make ARCH=armnommu CROSS_COMPILE=arm-uclinux- oldconfig 下面编译配置好的内核： [root@lisl linux-2.6.x]# make ARCH=armnommu CROSS_COMPILE=arm-uclinux- v=1 一般情况下，编译将顺利结束并在Linux-2.6.x/目录下生成未经压缩的μcLinux内核文件vmlinux。需要注意的是为了调试μcLinux内核，需要打开内核编译的调试选项-g，使编译后的内核带有调试信息。打开编译选项的方法可以选择： "Kernel debugging->

Debug options will be turned on automatically after "Compile the kernel with debug info". You can also directly modify the Makefile file in the linux-2.6.x directory to turn on the debug switch.

CFLAGS + =-g

The most common problem is that the error of the arm-uclinux-gcc command cannot be found, mainly because the PATH variable does not contain the directory where the arm-uclinux-gcc command is located. In the case of arm-linux-gcc 's default installation, its installation directory is / root/bin/arm-linux-tool/,. Use the following command to add the path to the PATH environment variable.

Export PATH=$PATH:/root/bin/arm-linux-tool/bin

The making of IV and root file system

One of the last actions of the Linux kernel at startup is to load the root file system. The root file system stores all the applications, library files and other services used by the embedded system. For the sake of the length of the article, we do not intend to introduce the production method of the root file system. Readers can consult some other relevant materials. It is worth noting that the root file system mounted into the kernel is specified by the configuration file skyeye.conf.

3.2 debugging using SkyEye

Once the μ cLinux kernel has been compiled, you can debug the kernel in the ELF executable format in SkyEye. As mentioned earlier, debugging a kernel with SkyEye is the same as debugging an application using gdb.

As a reminder, SkyEye's configuration file, skyeye.conf, records the hardware configuration and execution behavior of the simulation. This configuration file is a very important file in the SkyEye system, and many errors and exceptions are related to it. When there is an error installing the configuration SkyEye, please check the configuration file before doing anything else. At this point, all the preparatory work has been completed, and you are ready for kernel debugging.

3.3 characteristics and shortcomings of debugging kernels with SkyEye

The kernel of Linux system can be debugged in SkyEye. Since SkyEye currently mainly supports CPU based on the ARM kernel, it is generally necessary to use cross-compilation tools to compile the Linux kernel to be debugged. In addition, the process of kernel compilation and configuration used in making SkyEye is complicated and tedious. However, there is no need to remake the kernel to be released when the debugging process is over.

SkyEye only simulates the system hardware to a certain extent, so there is still a certain gap between SkyEye and the real hardware environment, which may have a certain impact on some debugging closely related to hardware, such as driver debugging. However, for most software debugging, SkyEye already provides simulations with sufficient precision.

The next goal of SkyEye is to combine with eclipse, with a graphical interface that makes it easier to debug and view source code.

Go back to the top of the page

4. Use UML to debug the Linux kernel

User-mode Linux (UML) is simply a Linux that runs within Linux. The project is to make the Linux kernel a separate, user-space process running on a Linux system. UML does not run on some new hardware architecture, but on a virtual machine based on Linux system call interface. Because UML is a feature that runs Linux as a user-space process, UML can be used to debug the operating system kernel. For an introduction to UML, please refer to references [10] and [12].

4.1installation and debugging of UML

The installation of UML requires an I386 machine running more than 2.2.15 or 2.3.22 Linux. For 2.6.8 and previous versions of UML, it is released in two forms: one is released as a RPM package, and the other is provided with an installation of UML as source code. According to UML's instructions, the installation packages provided in the form of RPM are old and have a lot of problems. The UML package released in binary form does not contain the required debugging information, and the code has been optimized to varying degrees at the time of release. Therefore, if you want to debug the Linux kernel with UML, you need to compile and install UML with the latest UML patch code and the corresponding version of the Linux kernel. After the patch for UML is completed, a um directory is generated under the arch directory, where the main UML code is placed.

Since version 2.6.9 (including version 2.6.9 of Linux), User-Mode Linux has been released with the Linux kernel source tree, which is stored in the arch/um directory.

After compiling the kernel of UML, run the compiled kernel directly using gdb to debug.

4.2 characteristics and shortcomings of debugging system kernels with UML

At present, the user-mode Linux virtual machine also has some limitations. Because the UML virtual machine is a virtual machine based on Linux system call interface, the user mode kernel cannot access the hardware devices on the host system. Therefore, UML is not suitable for debugging drivers that deal with actual hardware. However, if the kernel program you are writing is not a hardware driver, such as Linux file system, protocol stack, etc., it is still a good choice to use UML as a debugging tool.

Go back to the top of the page

5. Kernel debugging configuration options

To facilitate debugging and testing code, the kernel provides a number of configuration options related to kernel debugging. Most of these options are in the kernel development (kernel hacking) menu item of the kernel configuration editor. There are also some configurable debugging options elsewhere in the kernel configuration directory tree menu, which are described below.

Page alloc debugging: CONFIG_DEBUG_PAGEALLOC:

When this option is not used, the freed memory pages are removed from the kernel address space. With this option, the kernel delays the process of moving out of memory pages, so memory leaks can be found.

Debug memory allocations: CONFIG_DEBUG_SLAB:

When this option is turned on, multiple types of checks are performed before the kernel performs memory allocation, through which errors such as kernel overallocation or uninitialization can be found. The kernel will set some warning values before and after each memory allocation, and if these values change, the kernel will know that memory has been manipulated and give a clear hint, making obscure errors easy to track.

Spinlock debugging: CONFIG_DEBUG_SPINLOCK:

When this option is turned on, the kernel will be able to find spinlock uninitialized and various other errors, which can be used to eliminate some errors caused by deadlocks.

Sleep-inside-spinlock checking:CONFIG_DEBUG_SPINLOCK_SLEEP:

When this option is turned on, the appropriate check is performed when the holder of the spinlock wants to sleep. In fact, even if the caller is not sleeping at the moment, it will give a hint when there is only the possibility of sleep.

Compile the kernel with debug info: CONFIG_DEBUG_INFO:

When this option is turned on, the compiled kernel will contain all the debugging information that is required when using gdb.

Stack utilization instrumentation: CONFIG_DEBUG_STACK_USAGE:

This option is used to track kernel stack overflow errors. The obvious phenomenon of a kernel stack overflow error is that an oops error is generated without listing the system's call stack information. This option will cause the kernel to check for stack overflows and to count stack usage.

Driver Core verbose debug messages:CONFIG_DEBUG_DRIVER:

This option is located under "Device drivers- > Generic Driver Options". Turning on this option causes the kernel driver core to generate a large amount of debugging information and log them to the system log.

Verbose SCSI error reporting (kernel size + = 12K): CONFIG_SCSI_CONSTANTS:

This option is under "Device drivers/SCSI device support". The kernel will give detailed error information when the SCSI device goes wrong.

Event debugging:CONFIG_INPUT_EVBUG:

When this option is turned on, errors from the input subsystem and all events are output to the system log. This option not only produces a detailed input report, but also causes some security problems.

The above kernel compilation options require readers to choose flexibly according to the actual situation of their own kernel programming. When using the three source-level kernel debugging tools described above, you generally need to select the CONFIG_DEBUG_INFO option so that the compiled kernel contains debugging information.

Go back to the top of the page

6. Summary

The above introduces some methods of debugging Linux kernel, especially three kinds of kernel debugging tools at source code level and the methods of building these kernel debugging environment. Readers can choose from them according to their own situation.

The operation of debugging tools (such as gdb) needs the support of the operating system, and at this time, the kernel can not correctly perform the management functions of the system because of some incorrect code, so the debugging of the kernel must take some special methods. The three source code-level debugging methods described above can be summarized into the following two strategies:

I. Add debug Stub to the kernel and use debug Stub for remote debugging. This debugging strategy requires target and development machines to complete the debugging task.

II, combining virtual machine technology with debugging tools, makes the Linux kernel run in the virtual machine and uses the debugger to debug the kernel. This strategy requires the creation of a system kernel suitable for running in a virtual machine.

Different debugging strategies determine the different working principles of debugging, but also form a variety of debugging methods of different software and hardware requirements and their own characteristics.

In addition, it should be noted that the ability of kernel debugging depends to a large extent on experience and in-depth understanding of the entire operating system. A comprehensive and in-depth understanding of the system kernel will greatly speed up the development and debugging of the Linux system kernel.

Thank you for reading this article carefully. I hope the article "sample Analysis of Kernel debugging in Linux system" shared by the editor will be helpful to you. At the same time, I also hope that you will support and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.