Linux kernel Debugging Technology __linux

Linux Debugging

directory [-] pre-debug two-kernel BUG three-kernel Debug configuration option 1 Kernel configuration 2 debug atomic operation four raise bugs and print information 1 bugs () and bug_on () 2 dump_stack () five PRINTK () 1 PR Robustness of the INTK function 2 PRINTK function Vulnerability 3 log level 4 record buffer 5 SYSLOGD/KLOGD 6 DMESG 7 Note 8 kernel PRINTK and log system overall structure 9 dynamic Debugging six memory debugging tool 1 MEM WATCH 2 YAMD 3 electric Fence Seven strace eight OOPS 1 ksymoops 2 kallsyms 3 kdump nine KGDB 1 KGDB debugging principles 2 KGDB Installation and Setup 3 in VMware Build Debugging Environment 4 Kgdb some features and less than 10 use SkyEye build Linux kernel Debug Environment 1 SkyEye installation and μclinux kernel compilation 2 use SkyEye Debug 3 use SkyEye debug kernel features and less than 11 KD B 1 Getting Started 2 initializing and setting environment variable 3 activating KDB 4 KDB command 5 tips and tricks 6 closing 12 Kprobes 1 installing 2 writing Kprobes Module 3 using Kprobes better debug kernel development than user One of the more difficult aspects of space development is the difficulty of kernel debugging. Kernel errors often cause the system to go down and it is difficult to keep the scene when the error occurs. The key to debugging the kernel is your deep understanding of the kernel.

Preparation before commissioning Before debugging a bug, the preparation we have to do is:
There is a confirmed bug. The kernel version number containing the bug needs to be analyzed in which version of the bug is introduced, which is of great help in solving the problem. You can use the binary lookup method to gradually lock the bug into the version number. The deeper the understanding of the kernel code, the better, and the need for a little bit of luck. The bug can be reproduced. If you can find the recurrence rule, then the reason to find the problem is not far away. Minimize the system. Rule out the factors that could cause bugs.
two bugs in the kernelBugs in the kernel are also varied. They are produced for countless reasons, and appearances are also changeable. From the error hidden in the source code to the bug shown in front of the witness, the attack is often a series of chain-reaction events that may start. Although the kernel debugging has some difficulties, but through your efforts and understanding, perhaps you will like this challenge.

three-Kernel Debug configuration optionsLearn to write a driver to build your own kernel (the standard mainline kernel). One of the most important reasons is that the kernel developer has established several functions for debugging. However, because these features result in additional output and can degrade, distribution vendors typically prohibit debugging in the release kernel.

1 Kernel configuration

To implement kernel debugging, there are several additions to the kernel configuration: View source print?

01	Kernel Hacking--->

02	[*] Magic SYSRQ Key

03	[*] Kernel debugging

04	[*] Debug Slab Memory Allocations

05	[*] Spinlock and Rw-lock Debugging:basic checks

06	[*] Spinlock Debugging:sleep-inside-spinlock Checking

07	[*] Compile the kernel with debug info

08	Device Drivers--->

09	Generic Driver Options--->

10	[*] Driver Core verbose Debug messages

11	General Setup--->

12	[*] Configure standard kernel features (for small systems)--->

13	[*] Load all symbols for debugging/ksymoops

Enable options for example:
View Source print?

1	Slab layer Debugging (Slab layer Debug option)

2	High-memory Debugging (High-end memory debugging option)

3	I/O mapping Debugging (I/O mapping debugging Option)

4	Spin-lock Debugging (Spin lock debug option)

5	Stack-overflow Checking (Stack overflow check option)

6	Sleep-inside-spinlock checking (Spin lock sleep option)

2 Debugging atomic OperationsDeveloped from Kernel 2.5, the kernel provides an excellent tool for examining various issues raised by atomic operations.
The kernel provides an atomic operating counter that can be configured to print warning messages and provide tracking clues once the atom is in the process of entering sleep or doing some sleep-causing operations.
Therefore, all potential bugs can be detected by including the call to schedule () when using the lock and the blocking request for allocating memory when using the lock.
The following options allow you to maximize this feature:
View Source print?

1	Config_preempt = y

2	Config_debug_kernel = y

3	config_kllsyms = y

4	Config_spinlock_sleep = y

Four raising bugs and printing information 1 Bugs () and bug_on ()

Some kernel calls can be used to easily mark Bugs, provide assertions and output information. The two most commonly used are bugs () and bug_on ().

Defined in <include/asm-generic>:

View Source print?

01	#ifndef Have_arch_bug

02	#define BUG () do {

03	PRINTK ("Bug:failure at%s:%d/%s ()!", __file__, __line__, __function__);

04	Panic ("bug!"); /* Raise more serious error, not only print error message, and the whole system industry will suspend * *

05	} while (0)

06

#endif

07

08	#ifndef have_arch_bug_on

09	#define BUG_ON (condition) do {if (unlikely (condition)) BUG (), while (0)

10

#endif

When these two macros are invoked, they cause oops, which causes the stack's backtracking and error messages to print.
※ These two calls can be used as assertions, such as: bug_on (bad_thing);

2 dump_stack ()Sometimes, just print the stack's backtracking information on the terminal to help you debug. You can use Dump_stack () at this time. This function prints only the trace thread of the register context and function on the terminal.
View Source print?

1	if (!debug_check) {

2	PRINTK (kern_debug "provide some information.../n");

3	Dump_stack ();

4

}

five PRINTK () the formatted print function provided by the kernel.
The robustness and robustness of the 1 printk function is one of the most acceptable qualities of PRINTK, almost anywhere that the kernel can invoke it (interrupt context, process context, hold lock, multiprocessor processing, etc.).

2 PRINTK Function Vulnerability in the system startup process, before the terminal initialization, in some places can not be invoked. If you really need to debug the beginning of the system startup process, you can use the following methods:
Using serial port debugging, the debugging information is exported to other terminal equipment. Using EARLY_PRINTK (), this function has the ability to print early in the system startup. But it only supports part of the hardware system.

3 Log level PRINTK and printf A major difference is that the former can specify a log level. Kernel based on