精华内容
下载资源
问答
  • Linux 程序编译调试方法 Linux 程序编译调试方法
  • 嵌入式linux应用程序调试方法.doc
  • linux设备驱动程序调试方法》,很不错的Linux驱动的调试资料,希望对你的学习工作有所帮助。
  • Linux程序调试方法

    2012-10-02 20:04:19
    很多人可以利用vi编译器写程序,但是却不知道如何在vi编译器里调试程序,那么本文档为你解开迷惑
  • linux驱动程序调试方法

    千次阅读 2018-07-09 21:13:51
    来自:https://blog.csdn.net/caijp1090/article/details/7471862https://blog.csdn.net/gatieme/article/details/68948080 驱动程序开发的一个重大难点就是不易调试。本文目的就是介绍驱动开发中常用的几种直接和...

    来自:

    https://blog.csdn.net/caijp1090/article/details/7471862

    https://blog.csdn.net/gatieme/article/details/68948080

     

    驱动程序开发的一个重大难点就是不易调试。本文目的就是介绍驱动开发中常用的几种直接和间接的调试手段,它们是:

    利用printk

    查看OOP消息

    利用strace

    利用内核内置的hacking选项

    利用ioctl方法

    利用/proc 文件系统

    使用kgdb

    一、利用printk

    这是驱动开发中最朴实无华,同时也是最常用和有效的手段。scull驱动的main.c338行如下,就是使用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语句再重新加上。ohmy 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: it’s a placeholder */

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

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

    二、查看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.koarm-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}

    定位出错位置以及获取相关信息的过程:

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

    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)

    出错代码是faulty_write函数中的第5条指令((0xbf00608c-0xbf00607c)/4+1=5),该函数的首地址是0xbf00607c,该函数总共6条指令(0×18),该函数是被0xc0088eb8的前一条指令调用的(即:函数返回地址是0xc0088eb8。这一点可以从出错时lr的值正好等于0xc0088eb8得到印证)。调用该函数的指令是vfs_write的第49条(0xc4/4=49)指令。

    达到出错处的函数调用流程是:write(用户空间的系统调用)–>sys_write–>vfs_write–>faulty_write

    OOP消息不仅让我定位了出错的地方,更让我惊喜的是,它让我知道了一些秘密:1gccfp到底有何用处?2、为什么gcc编译任何函数的时候,总是要把3条看上去傻傻的指令放在整个函数的最开始?3、内核和gdb是如何知道函数调用栈顺序,并使用函数的名字而不是地址? 4、我如何才能知道各个函数入栈的内容?哈哈,我渐渐喜欢上了让内核惊讶,那就再看一次内核惊讶吧。

    执行 cat /dev/faulty,内核又再一次惊讶!

    1 Unable to handle kernel NULL pointer dereference at virtual address 0000000b
    2 pgd = c3a88000
    3 [0000000b] *pgd=33a79031, *pte=00000000, *ppte=00000000
    4 Internal error: Oops: 13 [#2] PREEMPT
    5 Modules linked in: faulty
    6 CPU: 0    Not tainted  (2.6.22.6 #4)
    7 PC is at vfs_read+0xe0/0×140
    8 LR is at 0xffffffff
    9 pc : [<c0088c84>]    lr : [<ffffffff>]    psr: 20000013
    10 sp : c38d9f54  ip : 0000001c  fp : ffffffff
    11 r10: 00000001  r9 : c38d8000  r8 : 00000000
    12 r7 : 00000004  r6 : ffffffff  r5 : ffffffff  r4 : ffffffff
    13 r3 : ffffffff  r2 : 00000000  r1 : c38d9f38  r0 : 00000004
    14 Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
    15 Control: c000717f  Table: 33a88000  DAC: 00000015
    16 Process cat (pid: 767, stack limit = 0xc38d8258)
    17 Stack: (0xc38d9f54 to 0xc38da000)
    18 9f40:                                              00002000 c3c105a0 c3c10580
    19 9f60: c38d9f78 00000000 c38d9fa4 c38d9f78 c0088f88 c0088bb4 00000000 00000000
    20 9f80: 00000000 00002000 bef07c80 00000003 00000003 c002c0e4 00000000 c38d9fa8
    21 9fa0: c002bf40 c0088f4c 00002000 bef07c80 00000003 bef07c80 00002000 00000000
    22 9fc0: 00002000 bef07c80 00000003 00000000 00000000 00000001 00000001 00000003
    23 9fe0: 00000000 bef07c6c 0000266c 401adab0 60000010 00000003 00000000 00000000
    24 Backtrace: invalid frame pointer 0xffffffff
    25 Code: ebffff86 e3500000 e1a07000 da000015 (e594500c)
    26 Segmentation fault

    不过这次惊讶却令人大为不解。OOP竟然说出错的地方在vfs_read(要知道它可是大拿们千锤百炼的内核代码),这怎么可能?哈哈,万能的内核也不能追踪函数调用栈了,这是为什么?其实问题出在faulty_read43行,它导致入栈的r4r5r6fp全部变为了0xffffffffiplr的值未变,这样一来faulty_read函数能够成功返回到它的调用者——vfs_read。但是可怜的vfs_read(忠实的APTCS规则遵守者)并不知道它的r4r5r6已经被万恶的faulty_read改变,这样下去vfs_read命运就可想而知了——必死无疑!虽然内核很有能力,但缺少了正确的fp的帮助,它也无法追踪函数调用栈。

    36 ssize_t faulty_read(struct file *filp, char __user *buf,
    37                     size_t count, loff_t *pos)
    38 {
    39         int ret;
    40         char stack_buf[4];
    41 
    42         /* Let’s try a buffer overflow  */
    43         memset(stack_buf, 0xff, 20);
    44         if (count > 4)
    45                 count = 4; /* copy 4 bytes to the user */
    46         ret = copy_to_user(buf, stack_buf, count);
    47         if (!ret)
    48                 return count;
    49         return ret;
    50 }

    00000000 <faulty_read>:
       0:   e1a0c00d        mov     ip, sp
       4:   e92dd870        stmdb   sp!, {r4, r5, r6, fp, ip, lr, pc}
       8:   e24cb004        sub     fp, ip, #4      ; 0×4
       c:   e24dd004        sub     sp, sp, #4      ; 0×4,这里为stack_buf[]在栈上分配1个字的空间,局部变量ret使用寄存器存储,因此就不在栈上分配空间了
      10:   e24b501c        sub     r5, fp, #28     ; 0x1c
      14:   e1a04001        mov     r4, r1
      18:   e1a06002        mov     r6, r2
      1c:   e3a010ff        mov     r1, #255        ; 0xff
      20:   e3a02014        mov     r2, #20 ; 0×14
      24:   e1a00005        mov     r0, r5
      28:   ebfffffe        bl      28 <faulty_read+0×28>  //这里在调用memset

      78:   e89da878        ldmia   sp, {r3, r4, r5, r6, fp, sp, pc}

    这次OOP,让我深刻地认识到:

    内核能力超强,但它不是,也不可能是万能的。所以即使你能力再强,也要和你的team member搞好关系,否则在关键时候你会倒霉的;

    出错的是faulty_readvfs_read却做了替罪羊。所以人不要被表面现象所迷惑,要深入看本质;

    内核本来超级健壮,可是你写的驱动是内核的组成部分,由于它出错,结果整体崩盘。所以当你加入一个团队的时候一定要告诫自己,虽然你的角色也许并不重要,但你的疏忽大意将足以令整个非常牛X的团队崩盘。反过来说,当你是team leader的时候,在选团队成员的时候一定要慎重、慎重、再慎重,即使他只是一个小角色。

    千万别惹堆栈,它一旦出问题,定位错误将会是一件非常困难的事情。所以,千万别惹你的领导,否则你将死得很难看。

    三、利用strace

    有时小问题可以通过监视程序监控用户应用程序的行为来追踪,同时监视程序也有助于建立对驱动正确工作的信心。例如,在看了它的读实现如何响应不同数量数据的读请求之后,我们能够对scull正在正确运行感到有信心。
    有几个方法来监视用户空间程序运行。你可以运行一个调试器来单步过它的函数,增加打印语句,或者在 strace 下运行程序。这里,我们将讨论最后一个技术,因为当真正目的是检查内核代码时,它是最有用的。
    strace 命令是一个有力工具,它能显示所有的用户空间程序发出的系统调用。它不仅显示调用,还以符号形式显示调用的参数和返回值。当一个系统调用失败, 错误的符号值(例如, ENOMEM)和对应的字串(Out of memory) 都显示。strace 有很多命令行选项,其中最有用的是 -t 来显示每个调用执行的时间,-T 来显示调用中花费的时间,-e 来限制被跟踪调用的类型(例如strace –eread,write  ls表示只监控readwrite调用),以及-o 来重定向输出到一个文件。缺省情况下,strace 打印调用信息到 stderr
    strace 从内核自身获取信息。这意味着可以跟踪一个程序,不管它是否带有调试支持编译(gcc -g 选项)以及不管它是否被strip过。此外,你也可以追踪一个正在运行中的进程,这类似于调试器连接到一个运行中的进程并控制它。
    跟踪信息常用来支持发给应用程序开发者的故障报告,但是对内核程序员也是很有价值的。我们已经看到驱动代码运行如何响应系统调用,strace 允许我们检查每个调用的输入和输出数据的一致性。
    例如,运行命令 strace ls /dev > /dev/scull0 将会在屏幕上显示如下的内容:
    open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
    fstat64(3, {st_mode=S_IFDIR|0755, st_size=24576, …}) = 0
    fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
    getdents64(3, /* 141 entries */, 4096) = 4088
    [...]
    getdents64(3, /* 0 entries */, 4096) = 0
    close(3) = 0
    [...]
    fstat64(1, {st_mode=S_IFCHR|0664, st_rdev=makedev(254, 0), …}) = 0
    write(1, "MAKEDEV\nadmmidi0\nadmmidi1\nadmmid"…, 4096) = 4000
    write(1, "b\nptywc\nptywd\nptywe\nptywf\nptyx0\n"…, 96) = 96
    write(1, "b\nptyxc\nptyxd\nptyxe\nptyxf\nptyy0\n"…, 4096) = 3904
    write(1, "s17\nvcs18\nvcs19\nvcs2\nvcs20\nvcs21"…, 192) = 192
    write(1, "\nvcs47\nvcs48\nvcs49\nvcs5\nvcs50\nvc"…, 673) = 673
    close(1) = 0
    exit_group(0) = ?
    从第一个 write 调用看, 明显地, ls 结束查看目标目录后,它试图写 4KB。但奇怪的是,只有 4000 字节被成功写入, 并且操作被重复。但当我们查看scull 中的写实现,发现它一次最多只允许写一个quantum(共4000字节),可见驱动本来就是期望部分写。几步之后, 所有东西清空, 程序成功退出。正是通过strace的输出,使我们确信驱动的部分写功能运行正确。
    作为另一个例子, 让我们读取 scull 设备(使用 wc scull0 命令):
    [...]
    open("/dev/scull0", O_RDONLY|O_LARGEFILE) = 3
    fstat64(3, {st_mode=S_IFCHR|0664, st_rdev=makedev(254, 0), …}) = 0
    read(3, "MAKEDEV\nadmmidi0\nadmmidi1\nadmmid"…, 16384) = 4000
    read(3, "b\nptywc\nptywd\nptywe\nptywf\nptyx0\n"…, 16384) = 4000
    read(3, "s17\nvcs18\nvcs19\nvcs2\nvcs20\nvcs21"…, 16384) = 865
    read(3, "", 16384) = 0
    fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), …}) = 0
    write(1, "8865 /dev/scull0\n", 17) = 17
    close(3) = 0
    exit_group(0) = ?
    如同期望的, read 一次只能获取 4000 字节,但是数据总量等同于前个例子写入的。这个例子,意外的收获是:可以肯定,wc 为快速读进行了优化,它因此绕过了标准库(没有使用fscanf),而是直接一个系统调用以读取更多数据。这一点,可从跟踪到的读的行里看到wc一次试图读取16 KB的数据而确认。

    四、利用内核内置的hacking选项

    内核开发者在make menuconfigKernel hacking提供了一些内核调试选项。这些选项有助于我们调试驱动程序,因为当我们启用某些调试选项的时候,操作系统会在发现驱动运行有问题时给出一些错误提示信息,而这些信息非常有助于驱动开发者找出驱动中的问题所在。下面就举几个简单例子。

    先启用如下选项:

    General setup — Configure standard kernel features (for small systems) — Load all symbols for debugging/ksymoops (NEW)

    Kernel hacking — Kernel debugging

    Device Drivers — Generic Driver Options — Driver Core verbose debug messages

    1Kernel debugging — Spinlock and rw-lock debugging: basic checks (NEW)可以检查到未初始化的自旋锁

    2Kernel debugging — Mutex debugging: basic checks (NEW) 可以检查到未初始化的信号量

    717                 //init_MUTEX(&scull_devices[i].sem);

    例如,如果我们忘记了初始化scull驱动中的信号量(将main.c的第717行注释掉),则在open设备scull时只会产生OOP,而没有其它信息提示我们有信号量未初始化,因此此时我们很难定位问题。相反,如果启用了上述选项,操作系统则会产生相关提示信息,使我们知道有未初始化的信号量或者自旋锁。从而,我们就可以去驱动代码中初始化信号量和自旋锁的地方修正程序。

    这个测试,我们的意外收获是:信号量的实现,其底层仍然是自旋锁。这与我们之前的大胆推测一致。

    process 751 enter scull_open
    BUG: spinlock bad magic on CPU#0, sh/751
    lock: c38ac1e4, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
    [<c002fe70>] (dump_stack+0×0/0×14) from [<c0130b5c>] (spin_bug+0×90/0xa4)
    [<c0130acc>] (spin_bug+0×0/0xa4) from [<c0130b98>] (_raw_spin_lock+0×28/0×160)
    r5:40000013 r4:c38ac1e4
    [<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025276c>] (_spin_lock_irqsave+0x2c/0×34)
    [<c0252740>] (_spin_lock_irqsave+0×0/0×34) from [<c0053d28>] (add_wait_queue_exclusive+0×24/0×50)
    r5:c38ac1e4 r4:c38a1e1c
    [<c0053d04>] (add_wait_queue_exclusive+0×0/0×50) from [<c024fcf0>] (__down_interruptible+0x5c/0x16c)
    r5:c38a0000 r4:c38ac1dc
    [<c024fc94>] (__down_interruptible+0×0/0x16c) from [<c024fb4c>] (__down_interruptible_failed+0xc/0×20)
    [<bf000530>] (scull_open+0×0/0xd8 [scull]) from [<c0088eb8>] (chrdev_open+0x1b4/0x1d8)
    r6:c3ef0300 r5:c38ac1fc r4:bf0045a0

    3Kernel debugging — Spinlock debugging: sleep-inside-spinlock checking (NEW) 可以检查出驱动在获取自旋锁后又睡眠以及死锁等状况

    345       ssleep(5);

    87 #define usespin

    例如,如果第1个进程在获得自旋锁的情况下睡眠(去掉main.c345行的注释,去掉scull.h87行的注释),当第2个进程试图获得自旋锁时将死锁系统。但如果启用了上面的选项,则在死锁前操作系统可以给出提示信息。

    process 763 enter read
    semphore get, and begin sleep 5 second in process 763
    BUG: scheduling while atomic: cat/0×00000001/763
    [<c002fe70>] (dump_stack+0×0/0×14) from [<c024fe64>] (schedule+0×64/0×778)
    [<c024fe00>] (schedule+0×0/0×778) from [<c02510a8>] (schedule_timeout+0x8c/0xbc)

    process 764 enter read
    BUG: spinlock cpu recursion on CPU#0, cat/764
    lock: c3ae7014, .magic: dead4ead, .owner: cat/763, .owner_cpu: 0
    [<c002fe70>] (dump_stack+0×0/0×14) from [<c0130b5c>] (spin_bug+0×90/0xa4)
    [<c0130acc>] (spin_bug+0×0/0xa4) from [<c0130bcc>] (_raw_spin_lock+0x5c/0×160)
    r5:beed2c70 r4:c3ae7014
    [<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025273c>] (_spin_lock+0×20/0×24)
    [<c025271c>] (_spin_lock+0×0/0×24) from [<bf000610>] (scull_read+0×64/0×210 [scull])
    r4:c3949520
    [<bf0005ac>] (scull_read+0×0/0×210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0×140)

    BUG: spinlock lockup on CPU#0, cat/764, c3ae7014
    [<c002fe70>] (dump_stack+0×0/0×14) from [<c0130c94>] (_raw_spin_lock+0×124/0×160)
    [<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025273c>] (_spin_lock+0×20/0×24)
    [<c025271c>] (_spin_lock+0×0/0×24) from [<bf000610>] (scull_read+0×64/0×210 [scull])
    r4:c3949520
    [<bf0005ac>] (scull_read+0×0/0×210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0×140)

    4Magic SysRq key可以在已经死锁的情况下,打印一些有助于定位问题的信息

    魔键 sysrq在大部分体系上都可用,它是用PC 键盘上 alt sysrq 键组合来发出的, 或者在别的平台上使用其他特殊键(详见 documentation/sysrq.txt), 在串口控制台上也可用。一个第三键, 与这2 个一起按下, 进行许多有用的动作中的一个:

    r 关闭键盘原始模式; 用在一个崩溃的应用程序( 例如 X 服务器 )可能将你的键盘搞成一个奇怪的状态.

    k 调用"安全注意键"( SAK ) 功能. SAK 杀掉在当前控制台的所有运行的进程, 给你一个干净的终端.

    s 进行一个全部磁盘的紧急同步.

    u umount. 试图重新加载所有磁盘在只读模式. 这个操作, 常常在 s 之后马上调用, 可以节省大量的文件系统检查时间, 在系统处于严重麻烦时.

    b boot. 立刻重启系统. 确认先同步和重新加载磁盘.

    p 打印处理器消息.

    t 打印当前任务列表.

    m 打印内存信息.

    例如,在系统死锁的情况下,期望能知道寄存器的值,则可以使用该魔法键。

    SysRq : Show Regs

    Pid: 764, comm:                  cat
    CPU: 0    Not tainted  (2.6.22.6 #6)
    PC is at _raw_spin_lock+0xbc/0×160
    LR is at _raw_spin_lock+0xcc/0×160
    pc : [<c0130c2c>]    lr : [<c0130c3c>]    psr: 60000013
    sp : c3b11ecc  ip : c3b11e08  fp : c3b11efc
    r10: c3b10000  r9 : 00000000  r8 : 055b131f
    r7 : c3ae7014  r6 : 00000000  r5 : 05f1e000  r4 : 00000000
    r3 : 00000000  r2 : c3b10000  r1 : 00000001  r0 : 00000001
    Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
    Control: c000717f  Table: 33b48000  DAC: 00000015
    [<c002cdb0>] (show_regs+0×0/0x4c) from [<c015ab00>] (sysrq_handle_showregs+0×20/0×28)
    r4:c0310c34
    [<c015aae0>] (sysrq_handle_showregs+0×0/0×28) from [<c015ad50>] (__handle_sysrq+0xa0/0×148)
    [<c015acb0>] (__handle_sysrq+0×0/0×148) from [<c015ae28>] (handle_sysrq+0×30/0×34)
    [<c015adf8>] (handle_sysrq+0×0/0×34) from [<c016477c>] (s3c24xx_serial_rx_chars+0x1b0/0x2d4)
    r5:00000000 r4:c03111e4
    [<c01645cc>] (s3c24xx_serial_rx_chars+0×0/0x2d4) from [<c0061474>] (handle_IRQ_event+0×44/0×80)
    [<c0061430>] (handle_IRQ_event+0×0/0×80) from [<c00629a8>] (handle_level_irq+0xd0/0×134)
    r7:c03073e8 r6:c3e52940 r5:00000046 r4:c03073bc
    [<c00628d8>] (handle_level_irq+0×0/0×134) from [<c0038118>] (s3c_irq_demux_uart+0×50/0×90)
    r7:00000000 r6:00000046 r5:00000001 r4:c03073bc
    [<c00380c8>] (s3c_irq_demux_uart+0×0/0×90) from [<c003816c>] (s3c_irq_demux_uart0+0×14/0×18)
    r6:c0336650 r5:0000002c r4:c0306cd4
    [<c0038158>] (s3c_irq_demux_uart0+0×0/0×18) from [<c002b044>] (asm_do_IRQ+0×44/0x5c)
    [<c002b000>] (asm_do_IRQ+0×0/0x5c) from [<c002ba78>] (__irq_svc+0×38/0xb0)
    Exception stack(0xc3b11e84 to 0xc3b11ecc)
    1e80:          00000001 00000001 c3b10000 00000000 00000000 05f1e000 00000000 
    1ea0: c3ae7014 055b131f 00000000 c3b10000 c3b11efc c3b11e08 c3b11ecc c0130c3c 
    1ec0: c0130c2c 60000013 ffffffff                                              
    r7:00000002 r6:10000000 r5:f0000000 r4:ffffffff
    [<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025273c>] (_spin_lock+0×20/0×24)
    [<c025271c>] (_spin_lock+0×0/0×24) from [<bf000610>] (scull_read+0×64/0×210 [scull])
    r4:c3949520
    [<bf0005ac>] (scull_read+0×0/0×210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0×140)
    [<c0085dec>] (vfs_read+0×0/0×140) from [<c00861d0>] (sys_read+0x4c/0×74)
    r7:00000000 r6:c3b11f78 r5:c3949520 r4:c3949540
    [<c0086184>] (sys_read+0×0/0×74) from [<c002bf00>] (ret_fast_syscall+0×0/0x2c)
    r8:c002c0a4 r7:00000003 r6:00000003 r5:beed2c70 r4:00002000

    5Debug shared IRQ handlers可用于调试共享中断

    五、利用ioctl方法

    由于驱动中的ioctl函数可以将驱动的一些信息返回给用户程序,也可以让用户程序通过ioctl系统调用设置一些驱动的参数。所以在驱动的开发过程中,可以扩展一些ioctl的命令用于传递和设置调试驱动时所需各种信息和参数,以达到调试驱动的目的。如何在驱动中实现ioctl,请参见驱动程序对ioctl的规范实现一文

    六、利用/proc 文件系统

    /proc文件系统用于内核向用户空间暴露一些内核的信息。因此出于调试的目的,我们可以在驱动代码中增加向/proc文件系统导出有助于监视驱动的信息的代码。这样一来,我们就可以通过查看/proc中的相关信息来监视和调试驱动。如何在驱动中实现向/proc文件系统导出信息,请参见《Linux Device Driver》的4.3节。

    七、使用kgdb

    kgdb是在内核源码中打用于调试内核的补丁,然后通过相应的硬件和软件,就可以像gdb单步调试应用程序一样来调试内核(当然包括驱动)。至于kgdb如何使用,就请你google吧,实在不行,百度一下也可以。boy, wish you good luck!

     

     

    展开全文
  • linux gdb运行不下去的程序调试方法.pdf
  • linux下的程序调试方法汇总

    千次阅读 2017-06-30 09:07:41
     搞电子都知道,电路不是焊接出来的,是调试...那么调试工具就显得尤为重要,Linux作为笔者重要的开发平台,在linux中讨论调试工具主要是为那些入门者提供一些帮助。调试工具能让我们能够监测、控制和纠正正在运

    原文地址:http://blog.csdn.net/guochaoxxl/article/details/51878051

       搞电子都知道,电路不是焊接出来的,是调试出来的。程序员也一定认同,程序不是写出来的,是调试出来的。那么调试工具就显得尤为重要,Linux作为笔者重要的开发平台,在linux中讨论调试工具主要是为那些入门者提供一些帮助。调试工具能让我们能够监测、控制和纠正正在运行的程序。我们在运行一些程序的时候,可能被卡住或出现错误,或者运行过程或结果,没能如我们预期,此时,最迫切需要明白究竟发生了什么。为了修复程序,剖析和了解程序运行的细节, 调试工具就成为了我们的必备工具,工于善其事,必先利其器。在Linux下的用户空间调试工具主要有系统工具和专门调试工具:'print' 打印语句,这是新手最常用的,也是最不提倡使用的;查询 (/proc, /sys 等)系统的虚拟文件查看,这个方法有局限性;跟踪 (strace/ltrace)工具使用这个比较普遍,值得提倡;Valgrind (memwatch)内存排除工具,在内存排除方面比较独到,是内存排错的法宝;GDB大名鼎鼎的程序调试工具,这个是个全能的工具,没有完不成的,只有你不知道的。

     

    1.'print' 语句

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

     

    2. 查询

           在某些情况下,我们需要弄清楚在一个运行在内核中的进程的状态和内存映射。为了获得这些信息,我们不需要在内核中插入任何代码。 相反,可以用 /proc 文件系统。在/proc的伪文件系统,保留系统启动运行就收集的运行时信息 (cpu信息, 内存容量等)。

          ls -l /proc'的输出结果,通过对 系统中运行的每一个进程在/proc文件系统中有一个以进程id命名的项。每个进程的细节信息可以在进程id对应的目录下的文件中获得。也可以'ls /proc/pid'的输出

    解释/proc文件系统内的所有条目超出了本文的范围。一些有用的列举如下:

    • /proc/cmdline -> 内核命令行
    • /proc/cpuinfo -> 关于处理器的品牌,型号信息等
    • /proc/filesystems -> 文件系统的内核支持的信息
    • /proc/<pid>/cmdline -> 命令行参数传递到当前进程
    • /proc/<pid>/mem -> 当前进程持有的内存
    • /proc/<pid>/status -> 当前进程的状态

     

    3. 跟踪

    strace的和ltrace是两个在Linux中用来追踪程序的执行细节的跟踪工具。

     

    strace:

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

    使用strace的基本语法是:

    strace 命令

    strace有各种各样的参数。可以检查看strace的手册页来获得更多的细节。

    strace的输出非常长,我们通常不会对显示的每一行都感兴趣。我们可以用'-e expr'选项来过滤不想要的数据。

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

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

    output of strace filtering only the open system call

    strace过滤成只有系统调用的输出

     

    ltrace:

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

    ltrace command

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

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

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

    output of ltrace capturing 'strcmp' library call

    ltrace捕捉'STRCMP'库调用的输出

     

    4. Valgrind

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

    • 内存泄露
    • 重释放
    • 访问越界
    • 使用未初始化的内存
    • 使用已经被释放的内存等。

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

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

    为了使用它,首先请下载并安装在你的系统上。可以使用操作系统上的包管理器来安装。

    使用命令行安装需要解压缩和解包下载的文件。

     
    1. tar -xjvf valgring-x.y.z.tar.bz2 (where x.y.z is the version number you are trying to install)

    进入新创建的目录(的valgrind-XYZ)内运行以下命令:

     
    1. ./configure
    2. make
    3. make install

    让我们通过一个小程序(test.c)来理解valgrind怎么工作的:

     
    1. #include <stdio.h>
    2.  
    3. void f(void)
    4.  
    5. {
    6. int x = malloc(10 * sizeof(int));
    7.  
    8. x[10] = 0;
    9. }
    10.  
    11. int main()
    12. {
    13. f();
    14. return 0;
    15. }

    编译程序:

     
    1. gcc -o test -g test.c

    现在我们有一个可执行文件叫做'test'。我们现在可以用valgrind来检测内存错误:

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

    这是valgrind呈现错误的输出:

    output of valgrind showing heap block overrun and memory leak

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

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

     

    5. GDB

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

    • 启动程序
    • 停在指定位置
    • 停在指定的条件
    • 检查所需信息
    • 改变程序中的数据 等。

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

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

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

     

    编译程序:

    为了用GDB调试程序,必须使用gcc的'-g'选项进行编译。这将以操作系统的本地格式产生调试信息,GDB利用这些信息来工作。

    下面是一个简单的程序(example1.c)执行被零除用来显示GDB的用法:

     
    1. #include
    2. int divide()
    3. {
    4. int x=5, y=0;
    5. return x / y;
    6. }
    7.  
    8. int main()
    9. {
    10. divide();
    11. }

    An example showing usage of gdb

    展示GDB用法的例子

     

    调用 GDB:

    通过在命令行中执行'gdb'来启动gdb:

    invoking gdb

    调用 gdb

    调用后, 它将等待终端命令并执行,直到退出。

    如果一个进程已经在运行,你需要将GDB连接到它上面,可以通过指定进程ID来实现。假设程序已经崩溃,要分析问题的原因,则用GDB分析core文件。

     

    启动程序:

    一旦你在GDB里面,使用'run'命令来启动程序进行调试。

     

    给程序传参数:

    使用'set args'给你的程序传参数,当程序下次运行时将获得该参数。'show args'将显示传递给程序的参数。

     

    检查堆栈:

    每当程序停止,任何人想明白的第一件事就是它为什么停止,以及怎么停在那里的。该信息被称为反向跟踪。由程序产生每个函数调用和局部变量,传递的参数,调用位置等信息一起存储在堆栈内的数据块种,被称为一帧。我们可以使用GDB来检查所有这些数据。 GDB从最底层的帧开始给这些帧编号。

    • bt: 打印整个堆栈的回溯
    • bt 打印n个帧的回溯
    • frame : 切换到指定的帧,并打印该帧
    • up : 上移'n'个帧
    • down : 下移'n'个帧 ( n默认是1)

     

    检查数据:

    程序的数据可以在里面GDB使用'print'命令进行检查。例如,如果'x'是调试程序内的变量,'print x'会打印x的值。

     

    检查源码:

    源码可以在GDB中打印。默认情况下,'list'命令会打印10行代码。

    • list : 列出'linenum'行周围的源码
    • list : 从'function'开始列出源码
    • disas : 显示该函数机器代码

     

    停止和恢复程序:

    使用GDB,我们可以在必要的地方设置断点,观察点等来停止程序。

    • break : 在'location'设置一个断点。当在程序执行到这里时断点将被击中,控制权被交给用户。
    • watch : 当'expr'被程序写入而且它的值发生变化时GDB将停止
    • catch : 当'event'发生时GDB停止
    • disable : 禁用指定断点
    • enable : 启用指定断点
    • delete : 删除 断点/观察点/捕获点。 如果没有传递参数默认操作是在所有的断点
    • step: 一步一步执行程序
    • continue: 继续执行程序,直到执行完毕

     

    退出 GDB:

    用'quit'命令还从GDB中退出。

    GDB还有更多的可用选项。里面GDB使用help选项了解更多详情。

    getting help within gdb

    在GDB中获得帮助

     

    总结

    在这篇文章中,我们已经看到不同类型的Linux用户空间的调试工具。总结以上所有内容,如下是什么时候使用该什么的快速指南:

    • 基本调试,获得关键变量 - print 语句
    • 获取有关文件系统支持,可用内存,CPU,运行程序的内核状态等信息 - 查询 /proc 文件系统
    • 最初的问题诊断,系统调用或库调用的相关问题,了解程序流程 – strace / ltrace
    • 应用程序内存空间的问题 – valgrind
    • 检查应用程序运行时的行为,分析应用程序崩溃 – gdb

    展开全文
  • linux下gdb调试方法与技巧整理

    万次阅读 多人点赞 2019-06-13 13:45:49
    目录一、gdb简介二、gdb使用流程1、启动gdb2、查看源码3、运行程序4、设置断点5、单步执行6、...GDB是一个由GNU开源组织发布的、UNIX/LINUX操作系统下的、基于命令行的、功能强大的程序调试工具。 对于一名Linux下...

    一、gdb简介

    GDB是一个由GNU开源组织发布的、UNIX/LINUX操作系统下的、基于命令行的、功能强大的程序调试工具。 对于一名Linux下工作的c/c++程序员,gdb是必不可少的工具;

    二、gdb使用流程

    这里用c程序做基本演示,c++程序也是一样的;

    1、启动gdb

    编译一个测试程序,-g表示可以调试,命令如下:

    gcc -g test.c -o test
    

    启动gdb,命令如下:

    gdb test 
    gdb -q test //表示不打印gdb版本信息,界面较为干净;
    

    测试如下:

    root@ubuntu:/home/eit/c_test# gdb test
    GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7
    Copyright (C) 2014 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from test...done.
    (gdb) q
    
    root@ubuntu:/home/eit/c_test# gdb -q test
    Reading symbols from test...done.
    (gdb) 
    

    到此gdb启动完成!

    2、查看源码

    list(简写 l): 查看源程序代码,默认显示10行,按回车键继续看余下的。
    测试如下:

    (gdb) list 
    9	#define MAX_SIZE
    10	
    11	int main()
    12	{
    13	    int i,fd,size1 ,size2 ,len;
    14	    char *buf = "helo!I'm liujiangyong ";
    15	    char buf_r[15];
    16	    len = strlen(buf);
    17	    fd = open("/home/hello.txt",O_CREAT | O_TRUNC | O_RDWR,0666);
    18	    if (fd<0)
    (gdb) 
    19	        {
    20	            perror("open :");
    21	            exit(1);
    22	        }
    23	    else
    24	        {
    25	        printf("open file:hello.txt %d\n",fd);
    26	        }
    27	    size1 = write(fd,buf,len);
    28	    if (fd<0)
    (gdb) 
    29	    {
    30	        printf("writre erro;");
    31	
    32	    }
    33	    else
    34	    {
    35	        printf("写入的长度:%d\n写入文本内容:%s\n",size1,buf);
    36	
    37	    }
    38	    lseek(fd,0,SEEK_SET);
    (gdb) 
    39	    size2 = read(fd,buf_r,12);
    40	    if (size2 <0)
    41	    {
    42	        printf("read  erro\n");
    43	    }
    44	    else
    45	    {
    46	        printf("读取长度:%d\n 文本内容是:%s\n",size2,buf_r);
    47	    }
    48	    close(fd);    
    (gdb) 
    49	
    50	
    51	}
    (gdb) 
    Line number 52 out of range; write.c has 51 lines.
    (gdb) 
    

    3、运行程序

    run(简写 r) :运行程序直到遇到 结束或者遇到断点等待下一个命令;
    测试如下:

    (gdb) r
    The program being debugged has been started already.
    Start it from the beginning? (y or n) y
    Starting program: /home/eit/c_test/test 
    open file:hello.txt 3
    写入的长度:22
    写入文本内容:helo!I'm liujiangyong 
    读取长度:12
     文本内容是:helo!I'm liu
    [Inferior 1 (process 19987) exited normally]
    (gdb) 
    

    4、设置断点

    break(简写 b) :格式 b 行号,在某行设置断点;
    info breakpoints :显示断点信息
    Num: 断点编号
    Disp:断点执行一次之后是否有效 kep:有效 dis:无效
    Enb: 当前断点是否有效 y:有效 n:无效
    Address:内存地址
    What:位置

    (gdb) b 5
    Breakpoint 3 at 0x400836: file write.c, line 5.
    (gdb) b 26 
    Breakpoint 4 at 0x4008a6: file write.c, line 26.
    (gdb) b 30
    Breakpoint 5 at 0x4008c6: file write.c, line 30.
    (gdb) info breakpoints 
    Num     Type           Disp Enb Address            What
    3       breakpoint     keep y   0x0000000000400836 in main at write.c:5
    4       breakpoint     keep y   0x00000000004008a6 in main at write.c:26
    5       breakpoint     keep y   0x00000000004008c6 in main at write.c:30
    (gdb) 
    

    5、单步执行

    使用 continue、step、next命令
    测试如下:

    (gdb) r
    Starting program: /home/eit/c_test/test 
    
    Breakpoint 3, main () at write.c:12
    12	{
    (gdb) n
    14	    char *buf = "helo!I'm liujiangyong ";
    (gdb) 
    16	    len = strlen(buf);
    (gdb) 
    17	    fd = open("/home/hello.txt",O_CREAT | O_TRUNC | O_RDWR,0666);
    (gdb) s
    open64 () at ../sysdeps/unix/syscall-template.S:81
    81	../sysdeps/unix/syscall-template.S: No such file or directory.
    (gdb) 
    main () at write.c:18
    18	    if (fd<0)
    (gdb) 
    25	        printf("open file:hello.txt %d\n",fd);
    (gdb) 
    __printf (format=0x400a26 "open file:hello.txt %d\n") at printf.c:28
    28	printf.c: No such file or directory.
    (gdb) c
    Continuing.
    open file:hello.txt 3
    
    Breakpoint 4, main () at write.c:27
    27	    size1 = write(fd,buf,len);
    (gdb) 
    Continuing.
    写入的长度:22
    写入文本内容:helo!I'm liujiangyong 
    读取长度:12
     文本内容是:helo!I'm liu
    [Inferior 1 (process 20737) exited normally]
    (gdb) 
    

    6、查看变量

    使用print、whatis命令
    测试如下:

    main () at write.c:28
    28	    if (fd<0)
    (gdb) 
    35	        printf("写入的长度:%d\n写入文本内容:%s\n",size1,buf);
    (gdb) print fd
    $10 = 3
    (gdb) whatis fd
    type = int
    (gdb) 
    
    

    7、退出gdb

    用quit命令退出gdb:

    (gdb) r
    Starting program: /home/eit/c_test/test 
    open file:hello.txt 3
    写入的长度:22
    写入文本内容:helo!I'm liujiangyong 
    读取长度:12
     文本内容是:helo!I'm liu
    [Inferior 1 (process 20815) exited normally]
    (gdb) q
    root@ubuntu:/home/eit/c_test# 
    
    

    continue(简写 c): 继续执行程序,直到下一个断点或者结束;
    next(简写 n ):单步执行程序,但是遇到函数时会直接跳过函数,不进入函数;
    step(简写 s) :单步执行程序,但是遇到函数会进入函数;
    until:当你厌倦了在一个循环体内单步跟踪时,这个命令可以运行程序直到退出循环体;
    until+行号: 运行至某行,不仅仅用来跳出循环;
    finish: 运行程序,直到当前函数完成返回,并打印函数返回时的堆栈地址和返回值及参数值等信息;
    call 函数(参数):调用程序中可见的函数,并传递“参数”,如:call gdb_test(55);
    quit:简记为 q ,退出gdb;

    三、gdb基本使用命令

    1、运行命令

    run:简记为 r ,其作用是运行程序,当遇到断点后,程序会在断点处停止运行,等待用户输入下一步的命令。
    continue (简写c ):继续执行,到下一个断点处(或运行结束)
    next:(简写 n),单步跟踪程序,当遇到函数调用时,也不进入此函数体;此命令同 step 的主要区别是,step 遇到用户自定义的函数,将步进到函数中去运行,而 next 则直接调用函数,不会进入到函数体内。
    step (简写s):单步调试如果有函数调用,则进入函数;与命令n不同,n是不进入调用的函数的
    until:当你厌倦了在一个循环体内单步跟踪时,这个命令可以运行程序直到退出循环体。
    until+行号: 运行至某行,不仅仅用来跳出循环
    finish: 运行程序,直到当前函数完成返回,并打印函数返回时的堆栈地址和返回值及参数值等信息。
    call 函数(参数):调用程序中可见的函数,并传递“参数”,如:call gdb_test(55)
    quit:简记为 q ,退出gdb

    2、设置断点

    break n (简写b n):在第n行处设置断点
    (可以带上代码路径和代码名称: b OAGUPDATE.cpp:578)
    b fn1 if a>b:条件断点设置
    break func(break缩写为b):在函数func()的入口处设置断点,如:break cb_button
    delete 断点号n:删除第n个断点
    disable 断点号n:暂停第n个断点
    enable 断点号n:开启第n个断点
    clear 行号n:清除第n行的断点
    info b (info breakpoints) :显示当前程序的断点设置情况
    delete breakpoints:清除所有断点:

    3、查看源码

    list :简记为 l ,其作用就是列出程序的源代码,默认每次显示10行。
    list 行号:将显示当前文件以“行号”为中心的前后10行代码,如:list 12
    list 函数名:将显示“函数名”所在函数的源代码,如:list main
    list :不带参数,将接着上一次 list 命令的,输出下边的内容。

    4、打印表达式

    print 表达式:简记为 p ,其中“表达式”可以是任何当前正在被测试程序的有效表达式,比如当前正在调试C语言的程序,那么“表达式”可以是任何C语言的有效表达式,包括数字,变量甚至是函数调用。
    print a:将显示整数 a 的值
    print ++a:将把 a 中的值加1,并显示出来
    print name:将显示字符串 name 的值
    print gdb_test(22):将以整数22作为参数调用 gdb_test() 函数
    print gdb_test(a):将以变量 a 作为参数调用 gdb_test() 函数
    display 表达式:在单步运行时将非常有用,使用display命令设置一个表达式后,它将在每次单步进行指令后,紧接着输出被设置的表达式及值。如: display a
    watch 表达式:设置一个监视点,一旦被监视的“表达式”的值改变,gdb将强行终止正在被调试的程序。如: watch a
    whatis :查询变量或函数
    info function: 查询函数
    扩展info locals: 显示当前堆栈页的所有变量

    5、查看运行信息

    where/bt :当前运行的堆栈列表;
    bt backtrace 显示当前调用堆栈
    up/down 改变堆栈显示的深度
    set args 参数:指定运行时的参数
    show args:查看设置好的参数
    info program: 来查看程序的是否在运行,进程号,被暂停的原因。

    6、分割窗口

    layout:用于分割窗口,可以一边查看代码,一边测试:
    layout src:显示源代码窗口
    layout asm:显示反汇编窗口
    layout regs:显示源代码/反汇编和CPU寄存器窗口
    layout split:显示源代码和反汇编窗口
    Ctrl + L:刷新窗口

    7、cgdb强大工具

    cgdb主要功能是在调试时进行代码的同步显示,这无疑增加了调试的方便性,提高了调试效率。界面类似vi,符合unix/linux下开发人员习惯;如果熟悉gdb和vi,几乎可以立即使用cgdb。

    8、常用gdb调试命令汇总

    在这里插入图片描述

    四、总结

    总的来说在Linux下开发程序gdb/cgdb是必须学会使用的,他的强大之处远不止于此,在程序的调试中用它会提高的我们的调试效率,当然gdb的功能与使用技巧还不止于此,多多探索,多多学习使用。

    参考链接:https://blog.csdn.net/horotororensu/article/details/82256832

    展开全文
  • 今天小编就为大家分享一篇关于Linux应用程序使用写文件调试程序方法,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
  • linux驱动程序调试常用方法

    万次阅读 2012-04-18 00:28:17
    驱动程序开发的一个重大难点就是不易调试。本文目的就是介绍驱动开发中常用的几种直接和间接的调试手段,它们是: 利用printk 查看OOP消息 利用strace 利用内核内置的hacking选项 利用ioctl方法 利用/proc 文件...

    驱动程序开发的一个重大难点就是不易调试。本文目的就是介绍驱动开发中常用的几种直接和间接的调试手段,它们是:

    • 利用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/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语句再重新加上。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: it’s a placeholder */

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

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

    二、查看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}

    定位出错位置以及获取相关信息的过程:

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

    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)

    出错代码是faulty_write函数中的第5条指令((0xbf00608c-0xbf00607c)/4+1=5),该函数的首地址是0xbf00607c,该函数总共6条指令(0×18),该函数是被0xc0088eb8的前一条指令调用的(即:函数返回地址是0xc0088eb8。这一点可以从出错时lr的值正好等于0xc0088eb8得到印证)。调用该函数的指令是vfs_write的第49条(0xc4/4=49)指令。

    达到出错处的函数调用流程是:write(用户空间的系统调用)–>sys_write–>vfs_write–>faulty_write

    OOP消息不仅让我定位了出错的地方,更让我惊喜的是,它让我知道了一些秘密:1、gcc中fp到底有何用处?2、为什么gcc编译任何函数的时候,总是要把3条看上去傻傻的指令放在整个函数的最开始?3、内核和gdb是如何知道函数调用栈顺序,并使用函数的名字而不是地址? 4、我如何才能知道各个函数入栈的内容?哈哈,我渐渐喜欢上了让内核惊讶,那就再看一次内核惊讶吧。

    执行 cat /dev/faulty,内核又再一次惊讶!

    1 Unable to handle kernel NULL pointer dereference at virtual address 0000000b
    2 pgd = c3a88000
    3 [0000000b] *pgd=33a79031, *pte=00000000, *ppte=00000000
    4 Internal error: Oops: 13 [#2] PREEMPT
    5 Modules linked in: faulty
    6 CPU: 0    Not tainted  (2.6.22.6 #4)
    7 PC is at vfs_read+0xe0/0×140
    8 LR is at 0xffffffff
    9 pc : [<c0088c84>]    lr : [<ffffffff>]    psr: 20000013
    10 sp : c38d9f54  ip : 0000001c  fp : ffffffff
    11 r10: 00000001  r9 : c38d8000  r8 : 00000000
    12 r7 : 00000004  r6 : ffffffff  r5 : ffffffff  r4 : ffffffff
    13 r3 : ffffffff  r2 : 00000000  r1 : c38d9f38  r0 : 00000004
    14 Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
    15 Control: c000717f  Table: 33a88000  DAC: 00000015
    16 Process cat (pid: 767, stack limit = 0xc38d8258)
    17 Stack: (0xc38d9f54 to 0xc38da000)
    18 9f40:                                              00002000 c3c105a0 c3c10580
    19 9f60: c38d9f78 00000000 c38d9fa4 c38d9f78 c0088f88 c0088bb4 00000000 00000000
    20 9f80: 00000000 00002000 bef07c80 00000003 00000003 c002c0e4 00000000 c38d9fa8
    21 9fa0: c002bf40 c0088f4c 00002000 bef07c80 00000003 bef07c80 00002000 00000000
    22 9fc0: 00002000 bef07c80 00000003 00000000 00000000 00000001 00000001 00000003
    23 9fe0: 00000000 bef07c6c 0000266c 401adab0 60000010 00000003 00000000 00000000
    24 Backtrace: invalid frame pointer 0xffffffff
    25 Code: ebffff86 e3500000 e1a07000 da000015 (e594500c)
    26 Segmentation fault

    不过这次惊讶却令人大为不解。OOP竟然说出错的地方在vfs_read(要知道它可是大拿们千锤百炼的内核代码),这怎么可能?哈哈,万能的内核也不能追踪函数调用栈了,这是为什么?其实问题出在faulty_read的43行,它导致入栈的r4、r5、r6、fp全部变为了0xffffffff,ip、lr的值未变,这样一来faulty_read函数能够成功返回到它的调用者——vfs_read。但是可怜的vfs_read(忠实的APTCS规则遵守者)并不知道它的r4、r5、r6已经被万恶的faulty_read改变,这样下去vfs_read命运就可想而知了——必死无疑!虽然内核很有能力,但缺少了正确的fp的帮助,它也无法追踪函数调用栈。

    36 ssize_t faulty_read(struct file *filp, char __user *buf,
    37                     size_t count, loff_t *pos)
    38 {
    39         int ret;
    40         char stack_buf[4];
    41
    42         /* Let’s try a buffer overflow  */
    43         memset(stack_buf, 0xff, 20);
    44         if (count > 4)
    45                 count = 4; /* copy 4 bytes to the user */
    46         ret = copy_to_user(buf, stack_buf, count);
    47         if (!ret)
    48                 return count;
    49         return ret;
    50 }

    00000000 <faulty_read>:
       0:   e1a0c00d        mov     ip, sp
       4:   e92dd870        stmdb   sp!, {r4, r5, r6, fp, ip, lr, pc}
       8:   e24cb004        sub     fp, ip, #4      ; 0×4
       c:   e24dd004        sub     sp, sp, #4      ; 0×4,这里为stack_buf[]在栈上分配1个字的空间,局部变量ret使用寄存器存储,因此就不在栈上分配空间了
      10:   e24b501c        sub     r5, fp, #28     ; 0x1c
      14:   e1a04001        mov     r4, r1
      18:   e1a06002        mov     r6, r2
      1c:   e3a010ff        mov     r1, #255        ; 0xff
      20:   e3a02014        mov     r2, #20 ; 0×14
      24:   e1a00005        mov     r0, r5
      28:   ebfffffe        bl      28 <faulty_read+0×28>  //这里在调用memset

      78:   e89da878        ldmia   sp, {r3, r4, r5, r6, fp, sp, pc}

    这次OOP,让我深刻地认识到:

    1. 内核能力超强,但它不是,也不可能是万能的。所以即使你能力再强,也要和你的team member搞好关系,否则在关键时候你会倒霉的;
    2. 出错的是faulty_read,vfs_read却做了替罪羊。所以人不要被表面现象所迷惑,要深入看本质;
    3. 内核本来超级健壮,可是你写的驱动是内核的组成部分,由于它出错,结果整体崩盘。所以当你加入一个团队的时候一定要告诫自己,虽然你的角色也许并不重要,但你的疏忽大意将足以令整个非常牛X的团队崩盘。反过来说,当你是team leader的时候,在选团队成员的时候一定要慎重、慎重、再慎重,即使他只是一个小角色。
    4. 千万别惹堆栈,它一旦出问题,定位错误将会是一件非常困难的事情。所以,千万别惹你的领导,否则你将死得很难看。

    三、利用strace

    有时小问题可以通过监视程序监控用户应用程序的行为来追踪,同时监视程序也有助于建立对驱动正确工作的信心。例如,在看了它的读实现如何响应不同数量数据的读请求之后,我们能够对scull正在正确运行感到有信心。
    有几个方法来监视用户空间程序运行。你可以运行一个调试器来单步过它的函数,增加打印语句,或者在 strace 下运行程序。这里,我们将讨论最后一个技术,因为当真正目的是检查内核代码时,它是最有用的。
    strace 命令是一个有力工具,它能显示所有的用户空间程序发出的系统调用。它不仅显示调用,还以符号形式显示调用的参数和返回值。当一个系统调用失败, 错误的符号值(例如, ENOMEM)和对应的字串(Out of memory) 都显示。strace 有很多命令行选项,其中最有用的是 -t 来显示每个调用执行的时间,-T 来显示调用中花费的时间,-e 来限制被跟踪调用的类型(例如strace –eread,write  ls表示只监控read和write调用),以及-o 来重定向输出到一个文件。缺省情况下,strace 打印调用信息到 stderr。
    strace 从内核自身获取信息。这意味着可以跟踪一个程序,不管它是否带有调试支持编译(对 gcc 是 -g 选项)以及不管它是否被strip过。此外,你也可以追踪一个正在运行中的进程,这类似于调试器连接到一个运行中的进程并控制它。
    跟踪信息常用来支持发给应用程序开发者的故障报告,但是对内核程序员也是很有价值的。我们已经看到驱动代码运行如何响应系统调用,strace 允许我们检查每个调用的输入和输出数据的一致性。
    例如,运行命令 strace ls /dev > /dev/scull0 将会在屏幕上显示如下的内容:
    open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
    fstat64(3, {st_mode=S_IFDIR|0755, st_size=24576, …}) = 0
    fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
    getdents64(3, /* 141 entries */, 4096) = 4088
    [...]
    getdents64(3, /* 0 entries */, 4096) = 0
    close(3) = 0
    [...]
    fstat64(1, {st_mode=S_IFCHR|0664, st_rdev=makedev(254, 0), …}) = 0
    write(1, "MAKEDEV\nadmmidi0\nadmmidi1\nadmmid"…, 4096) = 4000
    write(1, "b\nptywc\nptywd\nptywe\nptywf\nptyx0\n"…, 96) = 96
    write(1, "b\nptyxc\nptyxd\nptyxe\nptyxf\nptyy0\n"…, 4096) = 3904
    write(1, "s17\nvcs18\nvcs19\nvcs2\nvcs20\nvcs21"…, 192) = 192
    write(1, "\nvcs47\nvcs48\nvcs49\nvcs5\nvcs50\nvc"…, 673) = 673
    close(1) = 0
    exit_group(0) = ?
    从第一个 write 调用看, 明显地, 在 ls 结束查看目标目录后,它试图写 4KB。但奇怪的是,只有 4000 字节被成功写入, 并且操作被重复。但当我们查看scull 中的写实现,发现它一次最多只允许写一个quantum(共4000字节),可见驱动本来就是期望部分写。几步之后, 所有东西清空, 程序成功退出。正是通过strace的输出,使我们确信驱动的部分写功能运行正确。
    作为另一个例子, 让我们读取 scull 设备(使用 wc scull0 命令):
    [...]
    open("/dev/scull0", O_RDONLY|O_LARGEFILE) = 3
    fstat64(3, {st_mode=S_IFCHR|0664, st_rdev=makedev(254, 0), …}) = 0
    read(3, "MAKEDEV\nadmmidi0\nadmmidi1\nadmmid"…, 16384) = 4000
    read(3, "b\nptywc\nptywd\nptywe\nptywf\nptyx0\n"…, 16384) = 4000
    read(3, "s17\nvcs18\nvcs19\nvcs2\nvcs20\nvcs21"…, 16384) = 865
    read(3, "", 16384) = 0
    fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), …}) = 0
    write(1, "8865 /dev/scull0\n", 17) = 17
    close(3) = 0
    exit_group(0) = ?
    如同期望的, read 一次只能获取 4000 字节,但是数据总量等同于前个例子写入的。这个例子,意外的收获是:可以肯定,wc 为快速读进行了优化,它因此绕过了标准库(没有使用fscanf),而是直接一个系统调用以读取更多数据。这一点,可从跟踪到的读的行里看到wc一次试图读取16 KB的数据而确认。

    四、利用内核内置的hacking选项

    内核开发者在make menuconfig的Kernel hacking提供了一些内核调试选项。这些选项有助于我们调试驱动程序,因为当我们启用某些调试选项的时候,操作系统会在发现驱动运行有问题时给出一些错误提示信息,而这些信息非常有助于驱动开发者找出驱动中的问题所在。下面就举几个简单例子。

    先启用如下选项:

    • General setup — Configure standard kernel features (for small systems) — Load all symbols for debugging/ksymoops (NEW)
    • Kernel hacking — Kernel debugging
    • Device Drivers — Generic Driver Options — Driver Core verbose debug messages

    1、Kernel debugging — Spinlock and rw-lock debugging: basic checks (NEW)可以检查到未初始化的自旋锁

    2、Kernel debugging — Mutex debugging: basic checks (NEW) 可以检查到未初始化的信号量

    717                 //init_MUTEX(&scull_devices[i].sem);

    例如,如果我们忘记了初始化scull驱动中的信号量(将main.c的第717行注释掉),则在open设备scull时只会产生OOP,而没有其它信息提示我们有信号量未初始化,因此此时我们很难定位问题。相反,如果启用了上述选项,操作系统则会产生相关提示信息,使我们知道有未初始化的信号量或者自旋锁。从而,我们就可以去驱动代码中初始化信号量和自旋锁的地方修正程序。

    这个测试,我们的意外收获是:信号量的实现,其底层仍然是自旋锁。这与我们之前的大胆推测一致。

    process 751 enter scull_open
    BUG: spinlock bad magic on CPU#0, sh/751
    lock: c38ac1e4, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
    [<c002fe70>] (dump_stack+0×0/0×14) from [<c0130b5c>] (spin_bug+0×90/0xa4)
    [<c0130acc>] (spin_bug+0×0/0xa4) from [<c0130b98>] (_raw_spin_lock+0×28/0×160)
    r5:40000013 r4:c38ac1e4
    [<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025276c>] (_spin_lock_irqsave+0x2c/0×34)
    [<c0252740>] (_spin_lock_irqsave+0×0/0×34) from [<c0053d28>] (add_wait_queue_exclusive+0×24/0×50)
    r5:c38ac1e4 r4:c38a1e1c
    [<c0053d04>] (add_wait_queue_exclusive+0×0/0×50) from [<c024fcf0>] (__down_interruptible+0x5c/0x16c)
    r5:c38a0000 r4:c38ac1dc
    [<c024fc94>] (__down_interruptible+0×0/0x16c) from [<c024fb4c>] (__down_interruptible_failed+0xc/0×20)
    [<bf000530>] (scull_open+0×0/0xd8 [scull]) from [<c0088eb8>] (chrdev_open+0x1b4/0x1d8)
    r6:c3ef0300 r5:c38ac1fc r4:bf0045a0

    3、Kernel debugging — Spinlock debugging: sleep-inside-spinlock checking (NEW) 可以检查出驱动在获取自旋锁后又睡眠以及死锁等状况

    345       ssleep(5);

    87 #define usespin

    例如,如果第1个进程在获得自旋锁的情况下睡眠(去掉main.c第345行的注释,去掉scull.h第87行的注释),当第2个进程试图获得自旋锁时将死锁系统。但如果启用了上面的选项,则在死锁前操作系统可以给出提示信息。

    process 763 enter read
    semphore get, and begin sleep 5 second in process 763
    BUG: scheduling while atomic: cat/0×00000001/763
    [<c002fe70>] (dump_stack+0×0/0×14) from [<c024fe64>] (schedule+0×64/0×778)
    [<c024fe00>] (schedule+0×0/0×778) from [<c02510a8>] (schedule_timeout+0x8c/0xbc)

    process 764 enter read
    BUG: spinlock cpu recursion on CPU#0, cat/764
    lock: c3ae7014, .magic: dead4ead, .owner: cat/763, .owner_cpu: 0
    [<c002fe70>] (dump_stack+0×0/0×14) from [<c0130b5c>] (spin_bug+0×90/0xa4)
    [<c0130acc>] (spin_bug+0×0/0xa4) from [<c0130bcc>] (_raw_spin_lock+0x5c/0×160)
    r5:beed2c70 r4:c3ae7014
    [<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025273c>] (_spin_lock+0×20/0×24)
    [<c025271c>] (_spin_lock+0×0/0×24) from [<bf000610>] (scull_read+0×64/0×210 [scull])
    r4:c3949520
    [<bf0005ac>] (scull_read+0×0/0×210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0×140)

    BUG: spinlock lockup on CPU#0, cat/764, c3ae7014
    [<c002fe70>] (dump_stack+0×0/0×14) from [<c0130c94>] (_raw_spin_lock+0×124/0×160)
    [<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025273c>] (_spin_lock+0×20/0×24)
    [<c025271c>] (_spin_lock+0×0/0×24) from [<bf000610>] (scull_read+0×64/0×210 [scull])
    r4:c3949520
    [<bf0005ac>] (scull_read+0×0/0×210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0×140)

    4、Magic SysRq key可以在已经死锁的情况下,打印一些有助于定位问题的信息

    魔键 sysrq在大部分体系上都可用,它是用PC 键盘上 alt 和 sysrq 键组合来发出的, 或者在别的平台上使用其他特殊键(详见 documentation/sysrq.txt), 在串口控制台上也可用。一个第三键, 与这2 个一起按下, 进行许多有用的动作中的一个:

    • r 关闭键盘原始模式; 用在一个崩溃的应用程序( 例如 X 服务器 )可能将你的键盘搞成一个奇怪的状态.
    • k 调用"安全注意键"( SAK ) 功能. SAK 杀掉在当前控制台的所有运行的进程, 给你一个干净的终端.
    • s 进行一个全部磁盘的紧急同步.
    • u umount. 试图重新加载所有磁盘在只读模式. 这个操作, 常常在 s 之后马上调用, 可以节省大量的文件系统检查时间, 在系统处于严重麻烦时.
    • b boot. 立刻重启系统. 确认先同步和重新加载磁盘.
    • p 打印处理器消息.
    • t 打印当前任务列表.
    • m 打印内存信息.

    例如,在系统死锁的情况下,期望能知道寄存器的值,则可以使用该魔法键。

    SysRq : Show Regs

    Pid: 764, comm:                  cat
    CPU: 0    Not tainted  (2.6.22.6 #6)
    PC is at _raw_spin_lock+0xbc/0×160
    LR is at _raw_spin_lock+0xcc/0×160
    pc : [<c0130c2c>]    lr : [<c0130c3c>]    psr: 60000013
    sp : c3b11ecc  ip : c3b11e08  fp : c3b11efc
    r10: c3b10000  r9 : 00000000  r8 : 055b131f
    r7 : c3ae7014  r6 : 00000000  r5 : 05f1e000  r4 : 00000000
    r3 : 00000000  r2 : c3b10000  r1 : 00000001  r0 : 00000001
    Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
    Control: c000717f  Table: 33b48000  DAC: 00000015
    [<c002cdb0>] (show_regs+0×0/0x4c) from [<c015ab00>] (sysrq_handle_showregs+0×20/0×28)
    r4:c0310c34
    [<c015aae0>] (sysrq_handle_showregs+0×0/0×28) from [<c015ad50>] (__handle_sysrq+0xa0/0×148)
    [<c015acb0>] (__handle_sysrq+0×0/0×148) from [<c015ae28>] (handle_sysrq+0×30/0×34)
    [<c015adf8>] (handle_sysrq+0×0/0×34) from [<c016477c>] (s3c24xx_serial_rx_chars+0x1b0/0x2d4)
    r5:00000000 r4:c03111e4
    [<c01645cc>] (s3c24xx_serial_rx_chars+0×0/0x2d4) from [<c0061474>] (handle_IRQ_event+0×44/0×80)
    [<c0061430>] (handle_IRQ_event+0×0/0×80) from [<c00629a8>] (handle_level_irq+0xd0/0×134)
    r7:c03073e8 r6:c3e52940 r5:00000046 r4:c03073bc
    [<c00628d8>] (handle_level_irq+0×0/0×134) from [<c0038118>] (s3c_irq_demux_uart+0×50/0×90)
    r7:00000000 r6:00000046 r5:00000001 r4:c03073bc
    [<c00380c8>] (s3c_irq_demux_uart+0×0/0×90) from [<c003816c>] (s3c_irq_demux_uart0+0×14/0×18)
    r6:c0336650 r5:0000002c r4:c0306cd4
    [<c0038158>] (s3c_irq_demux_uart0+0×0/0×18) from [<c002b044>] (asm_do_IRQ+0×44/0x5c)
    [<c002b000>] (asm_do_IRQ+0×0/0x5c) from [<c002ba78>] (__irq_svc+0×38/0xb0)
    Exception stack(0xc3b11e84 to 0xc3b11ecc)
    1e80:          00000001 00000001 c3b10000 00000000 00000000 05f1e000 00000000
    1ea0: c3ae7014 055b131f 00000000 c3b10000 c3b11efc c3b11e08 c3b11ecc c0130c3c
    1ec0: c0130c2c 60000013 ffffffff                                             
    r7:00000002 r6:10000000 r5:f0000000 r4:ffffffff
    [<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025273c>] (_spin_lock+0×20/0×24)
    [<c025271c>] (_spin_lock+0×0/0×24) from [<bf000610>] (scull_read+0×64/0×210 [scull])
    r4:c3949520
    [<bf0005ac>] (scull_read+0×0/0×210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0×140)
    [<c0085dec>] (vfs_read+0×0/0×140) from [<c00861d0>] (sys_read+0x4c/0×74)
    r7:00000000 r6:c3b11f78 r5:c3949520 r4:c3949540
    [<c0086184>] (sys_read+0×0/0×74) from [<c002bf00>] (ret_fast_syscall+0×0/0x2c)
    r8:c002c0a4 r7:00000003 r6:00000003 r5:beed2c70 r4:00002000

    5、Debug shared IRQ handlers可用于调试共享中断

    五、利用ioctl方法

    由于驱动中的ioctl函数可以将驱动的一些信息返回给用户程序,也可以让用户程序通过ioctl系统调用设置一些驱动的参数。所以在驱动的开发过程中,可以扩展一些ioctl的命令用于传递和设置调试驱动时所需各种信息和参数,以达到调试驱动的目的。如何在驱动中实现ioctl,请参见“驱动程序对ioctl的规范实现”一文

    六、利用/proc 文件系统

    /proc文件系统用于内核向用户空间暴露一些内核的信息。因此出于调试的目的,我们可以在驱动代码中增加向/proc文件系统导出有助于监视驱动的信息的代码。这样一来,我们就可以通过查看/proc中的相关信息来监视和调试驱动。如何在驱动中实现向/proc文件系统导出信息,请参见《Linux Device Driver》的4.3节。

    七、使用kgdb

    kgdb是在内核源码中打用于调试内核的补丁,然后通过相应的硬件和软件,就可以像gdb单步调试应用程序一样来调试内核(当然包括驱动)。至于kgdb如何使用,就请你google吧,实在不行,百度一下也可以。boy, wish you good luck!

    展开全文
  • 嵌入式linux应用程序调试方法和流程 使用FS2410开发板
  • 点灯法(程序能运行到的地方点灯) 2.串口打印 3.调试器,JTAG,仿真器JTAG调试原理,硬件断点和软件断点http://blog.csdn.net/gowyz/article/details/7290701源码级调试可采用eclipse(封装了gdb工具)
  • 嵌入式linux应用程序的开发...如果建立了远程调试(能够在PC机ubuntu中调试板子中的linux应用程序),这样对于开发程序是极其方便的。以下是摘自网络上的一些方法。其中加入了自己所遇到的一些问题,并提出了解决方法
  • Linux程序调试--Bus Error

    万次阅读 2013-11-01 14:17:29
    Linux程序调试--Bus Error Bus Error究竟是指什么 一 Bus Error,即总线错误。  引发原因:  CPU出于性能方面的考虑,要求对数据进行访问时都必须是地址对齐的。如果发现进行的不是地址对齐的访问,就...
  • linux下的应用程序GDB调试方法,GDB是GNU开源组织发布的一个强大的UNIX下的程序调试工具
  • 培训第二天课程! Linux下C程序的GDB调试方法.pdf 下载时记住别遗漏哦!
  • linux gdb运行不下去的程序调试方法

    千次阅读 2015-11-11 12:05:48
    调试这样的程序有几种方法: 1、这些程序一般都是有while循环或者等待阻塞(例如服务器程序),这样的话,一般的可以让程序先运行起来,然后用gdb调试程序; 2、考虑另一种情况,如果在makeDaemon成功之后到...
  • GBD(linux下的程序调试).pdf

    热门讨论 2011-10-24 15:48:28
    linux下的gdb使用方法,教你如何在linux下进行程序调试 linux下的gdb使用方法,教你如何在linux下进行程序调试 linux下的gdb使用方法,教你如何在linux下进行程序调试 linux下的gdb使用方法,教你如何在linux下进行...
  • linux调试方法

    千次阅读 2012-11-22 11:38:11
    如何防止自己的程序调试器跟踪,这是一个很有趣的话题,也是反逆向工程中的一个重要话题。这里简单介绍一下Linux平台上的反调试技术。 (本文主要参考:...
  • Linux内核调试方法

    万次阅读 2012-03-22 15:38:10
    原文链接 ... kgdb:能很方便的在源码级对内核进行调试,缺点是kgdb只能进行远程调试,它需要一根串口线及两台机器来调试内核(也可以是在同一台主机上用vmware软件运行两个操作系统来调试) printk() 是调
  • linux程序无源码调试方法

    千次阅读 2017-06-24 19:36:16
    序过段时间可能要逆向linux上的cm, 先将调试方法做个实验, 将菜谱备好. 远程调试有2个方法: *GDB在linux服务器上直接调试无源码的cm,这个调试起来比较繁琐,即使没有源码,也是按照C语言代码行进行的单步。...
  • Linux下C程序的GDB调试方法,讲解精炼,很适合初学者实用。。。
  • linux 下的应用程序 GDB 调试方法 对于 linux 程序下的 C 设计要有好的程序设计规范能使得程序在调试过 程中节省很多时间而常出现类似于指针的段错误没有丰富的调试经验之下一 下子难得排错成功所在要借助其它软件的...
  • Linux内核调试方法总结

    千次阅读 2015-11-11 15:30:53
    ...一 调试前的准备 二 内核中的bug 三 内核调试配置选项 1 内核配置 2 调试原子操作 四 引发bug并打印信息 1 BUG()和BUG_ON() 2 dump_stack() 五 printk() 1 printk函数的健壮性
  • LINUX 多线程调试方法

    万次阅读 2018-04-02 16:50:36
    LINUX环境下的 多线程调试方法与总结 作为开发者的天堂,Linux为程序员提供了极其便利的方法和技巧,同时随着程序规模的增加,线程之间的绕来绕去,程序调试变得极其不稳定,因此,如何判断程序的问题出在哪里变得...
  • Linuxx86平台下程序崩溃的调试方法及量化分析

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 269,660
精华内容 107,864
关键字:

linux程序调试方法

linux 订阅