一、Linux驱动调试方法

        Linux驱动调试主要有以下几种方法：

                1、利用printk。

                2、查看OOP消息。

                3、利用strace。

                4、利用内核内置的hacking选项。

                5、利用ioctl方法。

                6、利用/proc 文件系统。

                7、使用kgdb。

1.1、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/printk

6 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语句再重新加上。所以，我们需要一种能方便地打开和关闭调试信息的手段。看看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: it’s a placeholder */

        这样一来，在开发驱动的过程中，如果想打印调试消息，我们就可以用PDEBUG(“address of i_cdev is %p\n”, inode->i_cdev);，如果不想看到该调试消息，就只需要简单的将PDEBUG改为PDEBUGG即可。而当我们调试完毕形成最终产品时，只需要简单地将第1行注释掉即可。

        上边那一段代码中的__KERNEL__是内核中定义的宏，当我们编译内核（包括模块）时，它会被定义。当然如果你不明白代码中的…和##是什么意思的话，就请认真查阅一下gcc关于预处理部分的资料吧！如果你实在太懒不愿意去查阅的话，那就充当VC工程师把上面的代码copy到你的代码中去吧。

1.2、查看OOP消息

        OOP意为惊讶。当你的驱动有问题，内核不惊讶才怪：嘿！小子，你干吗乱来！好吧，就让我们来看看内核是如何惊讶的。

        根据faulty.c（编译出faulty.ko，并 insmod faulty.ko。执行echo yang >/dev/faulty，结果内核就惊讶了。内核为什么会惊讶呢？因为faulty驱动的write函数执行了*(int *)0 = 0，向内存0地址写入，这是内核绝对不会容许的。

52 ssize_t faulty_write (struct file *filp, const char __user *buf, size_t count,

53 loff_t *pos)

54 {

55 /* make a simple fault by dereferencing a NULL pointer */

56 *(int *)0 = 0;

57 return 0;

58 }



1 Unable to handle kernel NULL pointer dereference at virtual address 00000000

2 pgd = c3894000

3 [00000000] *pgd=33830031, *pte=00000000, *ppte=00000000

4 Internal error: Oops: 817 [#1] PREEMPT

5 Modules linked in: faulty scull

6 CPU: 0 Not tainted (2.6.22.6 #4)

7 PC is at faulty_write+0×10/0×18 [faulty]

8 LR is at vfs_write+0xc4/0×148

9 pc : [<bf00608c>] lr : [<c0088eb8>] psr: a0000013

10 sp : c3871f44 ip : c3871f54 fp : c3871f50

11 r10: 4021765c r9 : c3870000 r8 : 00000000

12 r7 : 00000004 r6 : c3871f78 r5 : 40016000 r4 : c38e5160

13 r3 : c3871f78 r2 : 00000004 r1 : 40016000 r0 : 00000000

14 Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment user

15 Control: c000717f Table: 33894000 DAC: 00000015

16 Process sh (pid: 745, stack limit = 0xc3870258)

17 Stack: (0xc3871f44 to 0xc3872000)

18 1f40: c3871f74 c3871f54 c0088eb8 bf00608c 00000004 c38e5180 c38e5160

19 1f60: c3871f78 00000000 c3871fa4 c3871f78 c0088ffc c0088e04 00000000 00000000

20 1f80: 00000000 00000004 40016000 40215730 00000004 c002c0e4 00000000 c3871fa8

21 1fa0: c002bf40 c0088fc0 00000004 40016000 00000001 40016000 00000004 00000000

22 1fc0: 00000004 40016000 40215730 00000004 00000001 00000000 4021765c 00000000

23 1fe0: 00000000 bea60964 0000266c 401adb40 60000010 00000001 00000000 00000000

24 Backtrace:

25 [<bf00607c>] (faulty_write+0×0/0×18 [faulty]) from [<c0088eb8>] (vfs_write+0xc4/0×148)

26 [<c0088df4>] (vfs_write+0×0/0×148) from [<c0088ffc>] (sys_write+0x4c/0×74)

27 r7:00000000 r6:c3871f78 r5:c38e5160 r4:c38e5180

28 [<c0088fb0>] (sys_write+0×0/0×74) from [<c002bf40>] (ret_fast_syscall+0×0/0x2c)

29 r8:c002c0e4 r7:00000004 r6:40215730 r5:40016000 r4:00000004

30 Code: e1a0c00d e92dd800 e24cb004 e3a00000 (e5800000)

        1行惊讶的原因，也就是报告出错的原因。

        2-4行是OOP信息序号。

        5行是出错时内核已加载模块。

        6行是发生错误的CPU序号。

        7-15行是发生错误的位置，以及当时CPU各个寄存器的值，这最有利于我们找出问题所在地。

        16行是当前进程的名字及进程ID。

        17-23行是出错时，栈内的内容。

        24-29行是栈回溯信息，可看出直到出错时的函数递进调用关系（确保CONFIG_FRAME_POINTER被定义）。

        30行是出错指令及其附近指令的机器码，出错指令本身在小括号中。

        反汇编faulty.ko（ arm-linux-objdump -D faulty.ko > faulty.dis ；cat faulty.dis）可以看到如下的语句如下：

0000007c <faulty_write>:

7c: e1a0c00d mov ip, sp

80: e92dd800 stmdb sp!, {fp, ip, lr, pc}

84: e24cb004 sub fp, ip, #4 ; 0×4

88: e3a00000 mov r0, #0 ; 0×0

8c: e5800000 str r0, [r0]

90: e89da800 ldmia sp, {fp, sp, pc}

二、linux应用调试方法

2.1、'printf' 语句

        这是一个基本的调试问题的方法。 我们在程序中怀疑的地方插入print语句来了解程序的运行流程控制流和变量值的改变。 这是一个最简单的技术， 它的缺点。 需要进行程序编辑，添加'print'语句，必须重新编译，重新运行来获得输出。若需要调试的程序比较大，这将是一个耗时费力的方法。

2.2、strace

        strace拦截和记录系统调用及其接收的信号。对于用户，它显示了系统调用、传递给它们的参数和返回值。strace的可以附着到已在运行的进程或一个新的进程。它作为一个针对开发者和系统管理员的诊断、调试工具是很有用的。它也可以用来当做一个通过跟踪不同的程序调用来了解系统的工具。这个工具的好处是不需要源代码，程序也不需要重新编译。

        使用strace的基本语法是：strace 命令

        strace有各种各样的参数。可以检查看strace的手册页来获得更多的细节。 strace的输出非常长，我们通常不会对显示的每一行都感兴趣。我们可以用'-e expr'选项来过滤不想要的数据。

        用 '-p pid' 选项来绑到运行中的进程.

        用'-o'选项，命令的输出可以被重定向到文件。

         转存失败重新上传取消

2.3、ltrace

        ltrace跟踪和记录一个进程的动态（运行时）库的调用及其收到的信号。它也可以跟踪一个进程所作的系统调用。它的用法是类似与strace。

        ltrace command

                '-i' 选项在调用库时打印指令指针。

                '-S' 选项被用来现实系统调用和库调用

        所有可用的选项请参阅ltrace手册。

        转存失败重新上传取消

2.4、Valgrind

        Valgrind是一套调试和分析工具。它的一个被广泛使用的默认工具——'Memcheck'——可以拦截malloc()，new()，free()和delete()调用。换句话说，它在检测下面这些问题非常有用：

                1、内存泄露

                2、重释放

                3、访问越界

                4、使用未初始化的内存

                5、使用已经被释放的内存等。

        它直接通过可执行文件运行。

        Valgrind也有一些缺点，因为它增加了内存占用，会减慢你的程序。它有时会造成误报和漏报。它不能检测出静态分配的数组的访问越界问题。

        valgrind –tool=memcheck –leak-check=yes test

        转存失败重新上传取消

        valgrind显示堆溢出和内存泄漏的输出

        正如我们在上面看到的消息，我们正在试图访问函数f未分配的内存以及分配尚未释放的内存。

2.5、GDB

        GDB是来自自由软件基金会的调试器。它对定位和修复代码中的问题很有帮助。当被调试的程序运行时，它给用户控制权去执行各种动作， 比如：

                1、启动程序

                2、停在指定位置

                3、停在指定的条件

                4、检查所需信息

                5、改变程序中的数据 等。

        你也可以将一个崩溃的程序coredump附着到GDB并分析故障的原因。

        GDB提供很多选项来调试程序。 然而，我们将介绍一些重要的选择，来感受如何开始使用GDB。

        如果你还没有安装GDB，可以在这里下载：GDB官方网站。

三、Linux性能问题定位

3.1、基本流程

        如果你在Linux下碰到比较复杂的性能问题，记住，按照下面的４步走，会让你解决linux性能问题的时候事半功倍。

                1、先用top命令看linux系统总体的cpu使用情况。如果有异常，用pidstat -u查看细粒度的各个进程的cpu使用情况；否则，转向下一步。

                2、用vmstat命令查看linux系统总体的内存使用情况。如果有异常，用smem查看细粒度的各个进程的内存使用情况；否则，转向下一步。

                3、用iostat命令查看linux系统总体的IO使用情况。如果有异常，用iotop查看细粒度的各个进程的IO使用情况；否则，转向下一步。

                4、用iftop命令查看linux系统总体的网络使用情况。如果有异常，用nethogs查看细粒度的各个进程的网络带宽使用情况。

3.2、常用工具

        Linux下应用程序的cpu使用率较高，如何找到是哪段代码引起的？给你介绍这５个linux工具试试看！

                1、先看整体。通过top命令查看linux系统整体的cpu使用率和整体的平均负载；

                2、然后再看进程个体。通过pidstat -u 1查看linux下各个进程的cpu使用率，找到可疑进程；

                3、pstree -p {pid}查看进程的继承关系，这一步是可选的，但可以让我们清楚了解进程的族谱；

                4、strace -f -p {pid} 追踪进程的系统调用情况，确认是否存在频繁的系统调用？如果存在，就说明找到了根本原因；否则，继续下一步；

                5、pstack {pid}显示应用程序的实时的函数调用堆栈，从而找出性能瓶颈点；