Linux kernel device driver kernel debugging technical notes collation

/******************
 * Kernel debugging technology ********************/

(1) Some debugging-related configuration options in the kernel source code

The kernel configuration options include some options related to kernel debugging, all concentrated in the "kernel hacking" menu. include:

CONFIG_DEBUG_KERNEL

Makes additional debugging options available and should be checked; it does not by itself turn on all debugging features.

For detailed description of debugging options, please refer to the driver manual or view it through the help description of menuconfig.

(2) How to globally control printk debugging statements through macros

By cooperating with Makefile, we can define our own debugging statements in the c file.

(3) Use of strace

strace can trace all system calls issued by user space programs. Useful parameters are:

• -t shows the time when the call occurred
• -T Time spent on explicit calls
• -e limits the type of system calls being traced, such as "-e execve"
• -f trace all child processes
• -p trace a specific process. For example, "-p 8856"
• -o output information into a specific file

Strace is very useful for discovering subtle errors in system calls, especially for multi-process programs. You can get a lot of useful information through the return value and process pid output by strace. like:

$>strace -o zht.txt -f ./process_create

(4) Use of ltrace

ltrace can trace all dynamic library function calls issued by user space programs. Useful parameters are:

• -t shows the time when the call occurred
• -T Time spent on explicit calls
• -f trace all child processes
• -p trace a specific process
• -o output information into a specific file

(5) Check oops message

Oops is the kernel's most common way of notifying the user that something unfortunate has happened. Normally, after sending an oops, the kernel is left in an unstable state.

In some cases, an oops can cause a kernel panic, which results in a system crash. These situations may include:

• * Oops occurs in the code holding the lock
• *Oops occurs during communication with hardware devices
• *oops occurs in interrupt context
• *Oops occurs in the idle process (0) or the init process (1) because the kernel cannot work without these two processes

If the oops occurs while another process is running, the kernel will kill that process and try to continue running. Oops can occur for many reasons, including memory access out of bounds or illegal instructions.

The most important information contained in oops is the register context and the call trace, which can cause oops artificially, such as:

if(bad_thing)
 BUG();
//or BUG_ON(bad_thing);

You can use panic() to cause more serious errors. Calling panic() will not only print an error message, but also suspend the entire system. Only use in extremely dire circumstances:

if(terrible_thing)
 panic("foo is %ld!\n", foo);

Sometimes, just printing the stack information can help with testing, such as dump_stack():

 if(!debug_check){
  printk(KERNEL_DEBUG "provide some info\n");
  dump_stack();
 }

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM. If you want to learn more about this, please check out the following links