2.驱动程序调测方法和技巧.docVIP

第二章 驱动程序调测方法与技巧驱动程序开发的一个重大难点就是不易调试。本文目的就是介绍驱动开发中常用的几种直接和间接的调试手段，它们是： 利用printk 查看OOP消息 利用strace 利用内核内置的hacking选项 利用ioctl方法 利用/proc 文件系统 使用kgdb 一、利用printk 这是驱动开发中最朴实无华，同时也是最常用和有效的手段。scull驱动的main.c第338行如下，就是使用printk进行调试的例子，这样的例子相信大家在阅读驱动源码时随处可见。 338 //????????????? printk(KERN_ALERT wakeup by signal in process %d\n, current-pid); printk的功能与我们经常在应用程序中使用的printf是一样的，不同之处在于printk可以在打印字符串前面加上内核定义的宏，例如上面例子中的KERN_ALERT（注意：宏与字符串之间没有逗号）。 #define KERN_EMERG 0 #define KERN_ALERT 1 #define KERN_CRIT 2 #define KERN_ERR 3 #define KERN_WARNING 4 #define KERN_NOTICE 5 #define KERN_INFO 6 #define KERN_DEBUG 7 #define DEFAULT_CONSOLE_LOGLEVEL 7 这个宏是用来定义需要打印的字符串的级别。值越小，级别越高。内核中有个参数用来控制是否将printk打印的字符串输出到控制台（屏幕或者/sys/log/syslog日志文件） # cat /proc/sys/kernel/printk6?????? 4?????? 1?????? 7 第一个6表示级别高于（小于）6的消息才会被输出到控制台，第二个4表示如果调用printk时没有指定消息级别（宏）则消息的级别为4，第三个1表示接受的最高（最小）级别是1，第四个7表示系统启动时第一个6原来的初值是7。 因此，如果你发现在控制台上看不到你程序中某些printk的输出，请使用echo 8 /proc/sys/kernel/printk来解决。 我们在复杂驱动的开发过程中，为了调试会在源码中加入成百上千的printk语句。而当调试完毕形成最终产品的时候必然会将这些printk语句删除（为什么？想想你自己是驱动的使用者而不是开发者吧。记住：己所不欲，勿施于人），这个工作量是不小的。最要命的是，如果我们将调试用的printk语句删除后，用户又报告我们的驱动有bug，所以我们又不得不手工将这些上千条的printk语句再重新加上。oh，my god，杀了我吧。所以，我们需要一种能方便地打开和关闭调试信息的手段。哪里能找到这种手段呢？哈哈，远在天边，近在眼前。看看scull驱动或者leds驱动的源代码吧！ #define LEDS_DEBUG#undef PDEBUG???????????? /* undef it, just in case */#ifdef LEDS_DEBUG??? #ifdef __KERNEL__???? /* This one if debugging is on, and kernel space */??????? #define PDEBUG(fmt, args...) printk( KERN_EMERG leds: fmt, ## args)??? #else???? /* This one for user space */??????? #define PDEBUG(fmt, args...) fprintf(stderr, fmt, ## args)??? #endif#else??? #define PDEBUG(fmt, args...) /* not debugging: nothing */#endif#undef PDEBUGG#define PDEBUGG(fmt, args...) /* nothing: its a placeholder */ 这样一来，在开发驱动的过程中，如果想打印调试消息，我们就可以用PDEBUG(address of i_cdev is %p\n, inode-i_cdev);，如果不想看到该调试消息，就只需要简单的将PDEBUG改为PDEBUGG即可。而当我们调试完毕形成最终产品时，只需要简单地将第1行注释掉即可。 上边那一段代码中的__KERNEL__是内核中定义的宏，当我们编译内核（包括模块）时，它会被定义。当然如果你不明白代码中的...和##是什么