Linux Drive Design--Drive debugging technology

Refer to blogs and books:

"Linux Device Driver development"

"Linux Device Drivers"

Http://blog.chinaunix.net/uid-24219701-id-2884942.html

For the driver design, one of the core problems is how to complete the debugging. The current commonly used drive debugging technology can be divided into:

1. Print debugging

Printk

Redirecting console messages

Message logging

Turn message speed limits on and off

Print device number

2. Debugger Debugging

Gdb

KDB Kernel Debugger

Kgdb Patch　　

3. Query debugging

Using the/proc file system

Ioctl method

4. Monitoring debugging

　Oops message

5. Tool Kit

　　Dynamic Detection (Dprobes, a debugging tool)　

Linux Tracking Toolkit

Print Debugging (like debug macros that write applications that often compile with conditions)

PRINTK is very helpful in debugging when driving development. However , These print statements should be removed when the driver is formally released . But you may soon find that you need to implement a new feature in the driver ( or fix a bug), and then you have to use the deleted print statements. Here's a reasonable way to use printk to turn them on or off globally, rather than simply deleting them .

#ifdef pdebug#define plog (Fmt,args ...) printk (kern_debug "scull:" fmt,# #args) #else # define Plog (Fmt,args ...) /*do Nothing * * #endif

Makefile make the following changes:

Debug =yifeq ($ (debug), y) debflags =-o2-g-dpdebugelsedebflags =-o2endifcflags +=$ (debflags)

Instance:

/* * Output Debug information * Lzy 2011-9-26 */     #include <linux/init.h>             #include <linux/module.h>      #define Debug_ SWITCH 1   /*1: output 0: Do not output */#if debug_switch#define p_debug (Fmt,args ...) printk ("<kernel>:[%s]<Function> [%d] Line: "FMT, __function__, __line__, # #args) #else # define P_DEBUG (Fmt,args ...) /*do Nothing */#endifstatic int hello_init (void) {       char *name = "Lzy";    P_debug ("Hello%s\n", name);    /* Print Hello World */    return 0;} static void Hello_exit (void) {    p_debug ("Goodbye, world\n");   /* Print Goodbye,world */}module_init (hello_init);   /* Specify module Load function */module_exit (hello_exit);   /* Specify module Unload function */module_license ("GPL");

Debugging Tools: GDB, Kdb,kgdb

will need to compile the debug version kernel.

KDB Single-machine assembly-level debugging, need to download kernel corresponding patches separately,

gdb does not understand, only know that gdb Vmlinux after the start through the add-symobl-file to increase the symbol information of the debug module

KGDB in the 2.6.* after the default is placed in the kernel source, the other need to download patches separately, anyway, my 2.6.18 kernel is not (in kernel.org, People/ark should be able to find 2.6.18 patch, Note the order in which patches are played)

To see if there is a Kgdb method is: Under the source path make Menuconfig can see kgdb this item. The following is mainly about the establishment of the KGDB environment on 2.6.18:

Kgdb need two machines, a development machine, a test machine, two machines through the Serial line connection (the line is to be processed, specific to the window on the same as debugging drive)

A. Hardware connectivity test: Perform stty-ispeed 115200-ospeed 115200-f/DEV/TTYS0 on the development machine

Perform stty-ispeed 115200-ospeed 115200-f/dev/ttys0 on the test machine

Executing CAT/DEV/TTYS0 on the development machine

Perform echo "12345" </DEV/TTYS0 on the test machine

If you see 12345 on the development machine, it means two machines are connected.

B. Kernel compilation: Prepare the kernel source and corresponding kgdb patch files (I use the 2.6.18-92.EL5) on the development machine

Make Menuconfig pick up kgdb

Make modules

Make Modules_install (Install the compiled module file to the/lib/moudles/xxxx of the current system)

In the source file stored in the first level directory generated System.map file, under Arch/i386/boot generation Bzimage, the two files copied to/boot and renamed:

CP system.map/boot/system.map-2.6.18-92

CP bzimage/boot/vmlinuz-2.6.18-92

Create connection: Ln-s system.map-2.6.18-92 System.map

Ln-s vmlinuz-2.6.18-92 Vmlinuz

Make INITRD file: MKINITRD initrd-2.6.18-92 * * * * * * * * * * * * * * For new folder names created under/lib/modules when making Modules_install

C. Start a new compiled kernel

Open/boot/grub/grub.conf, this file is like the XP boot. ini, copy a

will correspond to the vmlinuz ... and initrd ... To be ready in the above steps, you need to increase the startup parameters as well:

Kgbwait kgdb8250=0,115200 (8250 should be supported in the KGDB patch used in this experiment)

This modification after the start will enter the status of such connections, generally on the development machine, you can first without kgdbwait kgdb8250 .... This parameter, so that the system can be started directly, so as to determine whether the newly compiled kernel is correct.

d. Layout test machine

After the step can ensure that the new kernel is started, vmlinuz-2.6.18-92 and initrd-26.18-92 two pieces to the test machine, and modify the startup item to start KGDB mode

E. Start kernel Debugging (note kernel debugging and kernel module debugging is not a concept)

On the development machine, execute GDB under the source path./vmlinux into GDB

Execute set Remotebaud 115200

Target REMOTE/DEV/TTYS0

If you see a breakpoint stop in KGDB.C after success, it means that you are connected to the tester at this time

Input c let the test machine continue to start, you can press CTRL + C to stop the tester at any time

After CTRL + C stops the tester, you can add breakpoints at the point where you want, and perform kernel single-step viewing debugging

F. If debugging a kernel module such as a driver module Test.ko need to use GDBMOD on the development machine instead of the GDB tool

Gdbmod./vmlinux start the debugger the same as the GDB operation

The key is how to trim the symbol files that are being debugged by the driver module (not trying to succeed because I want to debug the init function, at which time the driver is not trimmed)

Search on the internet is used under the gdbmod of the development machine, set S.....path to increase the symbol file path, so that on the test machine executed Insmod Test.ko Gdbmod on the development machine will be able to find Test.ko symbol file, but I did not try to succeed, and then try again

To be continue ... (Continuous improvement in the subsequent study)

　　

Linux Drive Design--Drive debugging technology