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

This article mainly introduces the example analysis of Linux kernel device driver kernel debugging technology, the article is very detailed, has a certain reference value, interested friends must read it!

/ * * Kernel debugging technology * /

(1) some configuration options related to debugging in kernel source code

Kernel configuration options include some options related to kernel debugging, all of which are concentrated in the "kernel hacking" menu. These include:

CONFIG_DEBUG_KERNEL

Make other debugging options available, should be selected, it itself will not turn on all debugging functions.

Specific debugging options can be described in the driver book, or through the help description of menuconfig.

(2) how to globally control printk debug statements through macros

By working with Makefile, we can define our own debug statements in the c file.

(3) the use of strace

Strace can track all system calls made by user-space programs. Useful parameters are:

-t shows the time when the call occurred

The time spent in explicit calls to-T

-e qualifies the type of system calls being tracked, such as "- e execve"

-f track all child processes

-p tracks specific processes. Such as "- p 8856"

-o Import the output information into a specific file

Strace is very useful for finding minor errors in system calls, especially for multi-process programs, and you can get a lot of useful information from the return value of the strace output and the process pid. Such as:

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

(4) the use of ltrace

Ltrace can track all dynamic library function calls made by user-space programs. Useful parameters are:

-t shows the time when the call occurred

The time spent in explicit calls to-T

-f track all child processes

-p track specific processes

-o Import the output information into a specific file

(5) View oops messages

Oops is the most common way for the kernel to inform users that something bad has happened. Usually, after sending the oops, the kernel is in an unstable state.

In some cases, oops can lead to kernel chaos, which results in a panic, which may include:

* oops occurs in the code that holds the lock

* oops occurs during communication with hardware devices

* oops occurs in the context of an interrupt

* oops occurs in the idle process (0) or the init process (1), because the kernel cannot work without these two processes

If oops occurs while another process is running, the kernel kills the process and tries to continue running. There are many reasons for oops, including memory access out of bounds or illegal instructions.

The most important information contained in oops is that register context and backtracking cues (call trace) can artificially cause oops, such as:

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

You can use panic () to raise a more serious error, and calling panic () not only prints the error message, but also hangs the entire system. It is used only in extreme circumstances:

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

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

If (! debug_check) {printk (KERNEL_DEBUG "provide some info\ n"); dump_stack ();} above are all the contents of this article entitled "sample Analysis of Linux Kernel device driver Kernel debugging Technology". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.