您的位置: 首页  >  IT文章  >  linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法 上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。

linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法 上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。

分类: IT文章 • 2023-03-07 14:48:53

如何根据oops定位代码行

我们借用linux设备驱动第二篇：构造和运行模块里面的hello world程序来演示出错的情况，含有错误代码的hello world如下：

[cpp] view plain copy
 
 linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法 上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法 上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。
  1. #include <linux/init.h>  
  2. #include <linux/module.h>  
  3. MODULE_LICENSE("Dual BSD/GPL");  
  4.   
  5. static int hello_init(void)  
  6. {  
  7.         char *p = NULL;  
  8.         memcpy(p, "test", 4);  
  9.         printk(KERN_ALERT "Hello, world ");  
  10.         return 0;  
  11. }  
  12. static void hello_exit(void)  
  13. {  
  14.   
  15.         printk(KERN_ALERT "Goodbye, cruel world ");  
  16. }  
  17.   
  18. module_init(hello_init);  
  19. module_exit(hello_exit);  

Makefile文件如下：








[cpp] view plain copy

 

 linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。





    

  1. ifneq ($(KERNELRELEASE),)  
    2. 

  2. obj-m := helloworld.o  
    3. 

  3. else  
    4. 

  4. KERNELDIR ?= /lib/modules/$(shell uname -r)/build  
    5. 

  5. PWD := $(shell pwd)  
    6. 

  6. default:  
    7. 

  7.         $(MAKE) -C $(KERNELDIR) M=$(PWD) modules  
    8. 

  8. endif  
    9. 

  9.   
    10. 

  10. clean:  
    11. 

  11.         rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c .tmp_versions modules.order  Module.symvers  
    12. 




很明显，以上代码的第8行是一个空指针错误。insmod后会出现下面的oops信息：








[plain] view plain copy

 

 linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。





    

  1. [  459.516441] BUG: unable to handle kernel NULL pointer dereference at           (null)  
    2. 

  2. [  459.516445] <span style="color:#ff0000;">IP: [<ffffffffc061400d>] hello_init+0xd/0x30 [helloworld]</span>  
    3. 

  3. [  459.516448] PGD 0   
    4. 

  4. [  459.516450] Oops: 0002 [#1] SMP   
    5. 

  5. [  459.516452] Modules linked in: helloworld(OE+) vmw_vsock_vmci_transport vsock coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel vmw_balloon snd_ens1371 aes_x86_64 lrw snd_ac97_codec gf128mul glue_helper ablk_helper cryptd ac97_bus gameport snd_pcm serio_raw snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer vmwgfx btusb ttm snd drm_kms_helper drm soundcore shpchp vmw_vmci i2c_piix4 rfcomm bnep bluetooth 6lowpan_iphc parport_pc ppdev mac_hid lp parport hid_generic usbhid hid psmouse ahci libahci floppy e1000 vmw_pvscsi vmxnet3 mptspi mptscsih mptbase scsi_transport_spi pata_acpi [last unloaded: helloworld]  
    6. 

  6. [  459.516476] CPU: 0 PID: 4531 Comm: insmod Tainted: G           OE 3.16.0-33-generic #44~14.04.1-Ubuntu  
    7. 

  7. [  459.516478] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014  
    8. 

  8. [  459.516479] task: ffff88003821f010 ti: ffff880038fa0000 task.ti: ffff880038fa0000  
    9. 

  9. [  459.516480] RIP: 0010:[<ffffffffc061400d>]  [<ffffffffc061400d>] hello_init+0xd/0x30 [helloworld]  
    10. 

  10. [  459.516483] RSP: 0018:ffff880038fa3d40  EFLAGS: 00010246  
    11. 

  11. [  459.516484] RAX: ffff88000c31d901 RBX: ffffffff81c1a020 RCX: 000000000004b29f  
    12. 

  12. [  459.516485] RDX: 000000000004b29e RSI: 0000000000000017 RDI: ffffffffc0615024  
    13. 

  13. [  459.516485] RBP: ffff880038fa3db8 R08: 0000000000015e80 R09: ffff88003d615e80  
    14. 

  14. [  459.516486] R10: ffffea000030c740 R11: ffffffff81002138 R12: ffff88000c31d0c0  
    15. 

  15. [  459.516487] R13: 0000000000000000 R14: ffffffffc0614000 R15: ffffffffc0616000  
    16. 

  16. [  459.516488] FS:  00007f8a6fa86740(0000) GS:ffff88003d600000(0000) knlGS:0000000000000000  
    17. 

  17. [  459.516489] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  
    18. 

  18. [  459.516490] CR2: 0000000000000000 CR3: 0000000038760000 CR4: 00000000003407f0  
    19. 

  19. [  459.516522] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  
    20. 

  20. [  459.516524] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  
    21. 

  21. [  459.516524] Stack:  
    22. 

  22. [  459.516537]  ffff880038fa3db8 ffffffff81002144 0000000000000001 0000000000000001  
    23. 

  23. [  459.516540]  0000000000000001 ffff880028ab5040 0000000000000001 ffff880038fa3da0  
    24. 

  24. [  459.516541]  ffffffff8119d0b2 ffffffffc0616018 00000000bd1141ac ffffffffc0616018  
    25. 

  25. [  459.516543] Call Trace:  
    26. 

  26. [  459.516548]  [<ffffffff81002144>] ? do_one_initcall+0xd4/0x210  
    27. 

  27. [  459.516550]  [<ffffffff8119d0b2>] ? __vunmap+0xb2/0x100  
    28. 

  28. [  459.516554]  [<ffffffff810ed9b1>] load_module+0x13c1/0x1b80  
    29. 

  29. [  459.516557]  [<ffffffff810e9560>] ? store_uevent+0x40/0x40  
    30. 

  30. [  459.516560]  [<ffffffff810ee2e6>] SyS_finit_module+0x86/0xb0  
    31. 

  31. [  459.516563]  [<ffffffff8176be6d>] system_call_fastpath+0x1a/0x1f  
    32. 

  32. [  459.516564] Code: <c7> 04 25 00 00 00 00 74 65 73 74 31 c0 48 89 e5 e8 a2 86 14 c1 31   
    33. 

  33. [  459.516573] RIP  [<ffffffffc061400d>] hello_init+0xd/0x30 [helloworld]  
    34. 

  34. [  459.516575]  RSP <ffff880038fa3d40>  
    35. 

  35. [  459.516576] CR2: 0000000000000000  
    36. 

  36. [  459.516578] ---[ end trace 7c52cc8624b7ea60 ]---  
    37. 




下面简单分析下oops信息的内容。


由BUG: unable to handle kernel NULL pointer dereference at           (null)知道出错的原因是使用了空指针。标红的部分确定了具体出错的函数。Modules linked in: helloworld表明了引起oops问题的具体模块。call trace列出了函数的调用信息。这些信息中其中标红的部分是最有用的，我们可以根据其信息找到具体出错的代码行。下面就来说下，如何定位到具体出错的代码行。


第一步我们需要使用objdump把编译生成的bin文件反汇编，我们这里就是helloworld.o，如下命令把反汇编信息保存到err.txt文件中：








[plain] view plain copy

 

 linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。





    

  1. objdump helloworld.o -D > err.txt  
    2. 





err.txt内容如下：








[plain] view plain copy

 


 linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。






    

  1. helloworld.o:     file format elf64-x86-64  
    2. 

  2.   
    3. 

  3.   
    4. 

  4. Disassembly of section .text:  
    5. 

  5.   
    6. 

  6. <span style="color:#ff0000;">0000000000000000 <init_module>:</span>  
    7. 

  7.    0:   e8 00 00 00 00          callq  5 <init_module+0x5>  
    8. 

  8.    5:   55                      push   %rbp  
    9. 

  9.    6:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi  
    10. 

  10.    d:   c7 04 25 00 00 00 00    movl   $0x74736574,0x0  
    11. 

  11.   14:   74 65 73 74   
    12. 

  12.   18:   31 c0                   xor    %eax,%eax  
    13. 

  13.   1a:   48 89 e5                mov    %rsp,%rbp  
    14. 

  14.   1d:   e8 00 00 00 00          callq  22 <init_module+0x22>  
    15. 

  15.   22:   31 c0                   xor    %eax,%eax  
    16. 

  16.   24:   5d                      pop    %rbp  
    17. 

  17.   25:   c3                      retq     
    18. 

  18.   26:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)  
    19. 

  19.   2d:   00 00 00   
    20. 

  20.   
    21. 

  21. 0000000000000030 <cleanup_module>:  
    22. 

  22.   30:   e8 00 00 00 00          callq  35 <cleanup_module+0x5>  
    23. 

  23.   35:   55                      push   %rbp  
    24. 

  24.   36:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi  
    25. 

  25.   3d:   31 c0                   xor    %eax,%eax  
    26. 

  26.   3f:   48 89 e5                mov    %rsp,%rbp  
    27. 

  27.   42:   e8 00 00 00 00          callq  47 <cleanup_module+0x17>  
    28. 

  28.   47:   5d                      pop    %rbp  
    29. 

  29.   48:   c3                      retq     
    30. 

  30.   
    31. 

  31. Disassembly of section .rodata.str1.1:  
    32. 

  32.   
    33. 

  33. 0000000000000000 <.rodata.str1.1>:  
    34. 

  34.    0:   01 31                   add    %esi,(%rcx)  
    35. 

  35.    2:   48                      rex.W  
    36. 

  36.    3:   65                      gs  
    37. 

  37.    4:   6c                      insb   (%dx),%es:(%rdi)  
    38. 

  38.    5:   6c                      insb   (%dx),%es:(%rdi)  
    39. 

  39.    6:   6f                      outsl  %ds:(%rsi),(%dx)  
    40. 

  40.    7:   2c 20                   sub    $0x20,%al  
    41. 

  41.    9:   77 6f                   ja     7a <cleanup_module+0x4a>  
    42. 

  42.    b:   72 6c                   jb     79 <cleanup_module+0x49>  
    43. 

  43.    d:   64 0a 00                or     %fs:(%rax),%al  
    44. 

  44.   10:   01 31                   add    %esi,(%rcx)  
    45. 

  45.   12:   47 6f                   rex.RXB outsl %ds:(%rsi),(%dx)  
    46. 

  46.   14:   6f                      outsl  %ds:(%rsi),(%dx)  
    47. 

  47.   15:   64                      fs  
    48. 

  48.   16:   62                      (bad)    
    49. 

  49.   17:   79 65                   jns    7e <cleanup_module+0x4e>  
    50. 

  50.   19:   2c 20                   sub    $0x20,%al  
    51. 

  51.   1b:   63 72 75                movslq 0x75(%rdx),%esi  
    52. 

  52.   1e:   65                      gs  
    53. 

  53.   1f:   6c                      insb   (%dx),%es:(%rdi)  
    54. 

  54.   20:   20 77 6f                and    %dh,0x6f(%rdi)  
    55. 

  55.   23:   72 6c                   jb     91 <cleanup_module+0x61>  
    56. 

  56.   25:   64 0a 00                or     %fs:(%rax),%al  
    57. 

  57.   
    58. 

  58. Disassembly of section .modinfo:  
    59. 

  59.   
    60. 

  60. 0000000000000000 <__UNIQUE_ID_license0>:  
    61. 

  61.    0:   6c                      insb   (%dx),%es:(%rdi)  
    62. 

  62.    1:   69 63 65 6e 73 65 3d    imul   $0x3d65736e,0x65(%rbx),%esp  
    63. 

  63.    8:   44 75 61                rex.R jne 6c <cleanup_module+0x3c>  
    64. 

  64.    b:   6c                      insb   (%dx),%es:(%rdi)  
    65. 

  65.    c:   20 42 53                and    %al,0x53(%rdx)  
    66. 

  66.    f:   44 2f                   rex.R (bad)   
    67. 

  67.   11:   47 50                   rex.RXB push %r8  
    68. 

  68.   13:   4c                      rex.WR  
    69. 

  69.     ...  
    70. 

  70.   
    71. 

  71. Disassembly of section .comment:  
    72. 

  72.   
    73. 

  73. 0000000000000000 <.comment>:  
    74. 

  74.    0:   00 47 43                add    %al,0x43(%rdi)  
    75. 

  75.    3:   43 3a 20                rex.XB cmp (%r8),%spl  
    76. 

  76.    6:   28 55 62                sub    %dl,0x62(%rbp)  
    77. 

  77.    9:   75 6e                   jne    79 <cleanup_module+0x49>  
    78. 

  78.    b:   74 75                   je     82 <cleanup_module+0x52>  
    79. 

  79.    d:   20 34 2e                and    %dh,(%rsi,%rbp,1)  
    80. 

  80.   10:   38 2e                   cmp    %ch,(%rsi)  
    81. 

  81.   12:   32 2d 31 39 75 62       xor    0x62753931(%rip),%ch        # 62753949 <cleanup_module+0x62753919>  
    82. 

  82.   18:   75 6e                   jne    88 <cleanup_module+0x58>  
    83. 

  83.   1a:   74 75                   je     91 <cleanup_module+0x61>  
    84. 

  84.   1c:   31 29                   xor    %ebp,(%rcx)  
    85. 

  85.   1e:   20 34 2e                and    %dh,(%rsi,%rbp,1)  
    86. 

  86.   21:   38 2e                   cmp    %ch,(%rsi)  
    87. 

  87.   23:   32 00                   xor    (%rax),%al  
    88. 

  88.   
    89. 

  89. Disassembly of section __mcount_loc:  
    90. 

  90.   
    91. 

  91. 0000000000000000 <__mcount_loc>:  
    92. 






由oops信息我们知道出错的地方是hello_init的地址偏移0xd。而有dump信息知道，hello_init的地址即init_module的地址，因为hello_init即本模块的初始化入口，如果在其他函数中出错，dump信息中就会有相应符号的地址。由此我们得到出错的地址是0xd，下一步我们就可以使用addr2line来定位具体的代码行：








[plain] view plain copy

 


 linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。linux设备驱动第四篇：从如何定位oops的代码行谈驱动调试方法
上一篇我们大概聊了如何写一个简单的字符设备驱动，我们不是神，写代码肯定会出现问题，我们需要在编写代码的过程中不断调试。在普通的c应用程序中，我们经常使用printf来输出信息，或者使用gdb来调试程序，那么驱动程序如何调试呢？我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题，在应用程序中运行这种程序就会报segmentation fault的错误，而由于驱动程序的特殊性，出现此类情况后往往会直接造成系统宕机，并会抛出oops信息。那么我们如何来分析oops信息呢，甚至根据oops信息来定位具体的出错的代码行呢？下面就根据一个简单的实例来说明如何调试驱动程序。






    

  1. addr2line -C -f -e helloworld.o d  
    2. 






此命令就可以得到行号了。以上就是通过oops信息来定位驱动崩溃的行号。



其他调试手段


以上就是通过oops信息来获取具体的导致崩溃的代码行，这种情况都是用在遇到比较严重的错误导致内核挂掉的情况下使用的，另外比较常用的调试手段就是使用printk来输出打印信息。printk的使用方法类似printf，只是要注意一下打印级别，详细介绍在Linux设备驱动第二篇：构造和运行模块中已有描述，另外需要注意的是大量使用printk会严重拖慢系统，所以使用过程中也要注意。


以上两种调试手段是我工作中最常用的，还有一些其他的调试手段，例如使用/proc文件系统，使用trace等用户空间程序，使用gdb，kgdb等，这些调试手段一般不太容易使用或者不太方便使用，所以这里就不在介绍了。


介绍完驱动的调试方法后，下一篇会介绍下linux驱动的并发与竞态，欢迎关注。



http://blog.csdn.net/haomcu/article/details/44810709



															

																					

								

									相关推荐