Linux-hexdump命令调试event驱动

hexdump: 查看文件的内容，比如二进制文件中包含的某些字符串,通常用来调试驱动用

描述

我们以event1为例,当我们insmod挂载了键盘驱动后,出现一个event1设备,

此时没有按键按下，所以event1里面的数据是没有的,那么数据又是从来哪里来？

通过键盘驱动的read函数,若有按键按下,就会上游梁传按键数据给用户层hexdump

因为键盘驱动的input_handler 是:evdev_handler

所以键盘驱动的read函数是: evdev_handler->evdev_fops->evdev_read

进入evdev_read()函数,如下图所示:

evdev_event_to_user()这个函数从字面上来看,显然就是用来上传给用户层的函数,其神此运中buffer是函数参数,指向用户层,所以数据就是event.

我们来看看event的结构体:input_event

把 time里的成员展开如下:

所以我们hexdump调试任何输入子系统event XX驱动时,有信息就会打印上面数据

1.调试键扒液盘驱动

以按开发板的按键 KEY_L,为例(因为数据是从低到高打印的,所以数据是反的):

如何根据oops定位代码行

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

#include <linux/init.h>

#include <linux/module.h>

MODULE_LICENSE("Dual BSD/GPL")

static int hello_init(void)

{

char *p = NULL

memcpy(p, "test", 4)

printk(KERN_ALERT "Hello, world\n")

return 0

}

static void hello_exit(void)

{

printk(KERN_ALERT "Goodbye, cruel world\n")

}

module_init(hello_init)

module_exit(hello_exit)

Makefile文件如下：

1

2

3

4

5

6

7

8

9

10

11

ifneq ($(KERNELRELEASE),)

obj-m := helloworld.o

else

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

PWD := $(shell pwd)

default:

$(MAKE) -C $(KERNELDIR) M=$(PWD) modules

endif

clean:

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

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

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

[ 459.516445]

[ 459.516448] PGD 0

[ 459.516450] Oops: 0002 [#1] SMP

[ 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]

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

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

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

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

[ 459.516483] RSP: 0018:ffff880038fa3d40 EFLAGS: 00010246

[ 459.516484] RAX: ffff88000c31d901 RBX: ffffffff81c1a020 RCX: 000000000004b29f

[ 459.516485] RDX: 000000000004b29e RSI: 0000000000000017 RDI: ffffffffc0615024

[ 459.516485] RBP: ffff880038fa3db8 R08: 0000000000015e80 R09: ffff88003d615e80

[ 459.516486] R10: ffffea000030c740 R11: ffffffff81002138 R12: ffff88000c31d0c0

[ 459.516487] R13: 0000000000000000 R14: ffffffffc0614000 R15: ffffffffc0616000

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

[ 459.516489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

[ 459.516490] CR2: 0000000000000000 CR3: 0000000038760000 CR4: 00000000003407f0

[ 459.516522] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[ 459.516524] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

[ 459.516524] Stack:

[ 459.516537] ffff880038fa3db8 ffffffff81002144 0000000000000001 0000000000000001

[ 459.516540] 0000000000000001 ffff880028ab5040 0000000000000001 ffff880038fa3da0

[ 459.516541] ffffffff8119d0b2 ffffffffc0616018 00000000bd1141ac ffffffffc0616018

[ 459.516543] Call Trace:

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

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

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

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

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

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

[ 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

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

[ 459.516575] RSP <ffff880038fa3d40>

[ 459.516576] CR2: 0000000000000000

[ 459.516578] ---[ end trace 7c52cc8624b7ea60 ]---

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

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

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

1

objdump helloworld.o -D >err.txt

err.txt内容如下：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

helloworld.o: file format elf64-x86-64

Disassembly of section .text:

<span style="color:#ff0000">0000000000000000 <init_module>:</span>

0: e8 00 00 00 00 callq 5 <init_module+0x5>

5: 55 push %rbp

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

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

14: 74 65 73 74

18: 31 c0 xor%eax,%eax

1a: 48 89 e5mov%rsp,%rbp

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

22: 31 c0 xor%eax,%eax

24: 5d pop%rbp

25: c3 retq

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

2d: 00 00 00

0000000000000030 <cleanup_module>:

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

35: 55 push %rbp

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

3d: 31 c0 xor%eax,%eax

3f: 48 89 e5mov%rsp,%rbp

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

47: 5d pop%rbp

48: c3 retq

Disassembly of section .rodata.str1.1:

0000000000000000 <.rodata.str1.1>:

0: 01 31 add%esi,(%rcx)

2: 48 rex.W

3: 65 gs

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

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

6: 6f outsl %ds:(%rsi),(%dx)

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

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

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

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

10: 01 31 add%esi,(%rcx)

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

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

15: 64 fs

16: 62 (bad)

17: 79 65 jns7e <cleanup_module+0x4e>

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

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

1e: 65 gs

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

20: 20 77 6fand%dh,0x6f(%rdi)

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

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

Disassembly of section .modinfo:

0000000000000000 <__UNIQUE_ID_license0>:

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

1: 69 63 65 6e 73 65 3dimul $0x3d65736e,0x65(%rbx),%esp

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

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

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

f: 44 2f rex.R (bad)

11: 47 50 rex.RXB push %r8

13: 4c rex.WR

...

Disassembly of section .comment:

0000000000000000 <.comment>:

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

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

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

9: 75 6e jne79 <cleanup_module+0x49>

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

d: 20 34 2eand%dh,(%rsi,%rbp,1)

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

12: 32 2d 31 39 75 62 xor0x62753931(%rip),%ch# 62753949 <cleanup_module+0x62753919>

18: 75 6e jne88 <cleanup_module+0x58>

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

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

1e: 20 34 2eand%dh,(%rsi,%rbp,1)

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

23: 32 00 xor(%rax),%al

Disassembly of section __mcount_loc:

0000000000000000 <__mcount_loc>:

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

addr2line -C -f -e helloworld.o d

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

其他调试手段

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

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

一、Linux device driver 的概念\x0d\x0a\x0d\x0a系统调用是 *** 作系统内核和应用程序之间的接口，设备驱动程序是 *** 作系统内核和机器硬件之间的接枣圆口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象 *** 作普通文件一样对硬件设备进行 *** 作。设备驱动程序是内核的一部分，它完成以下的功能:\x0d\x0a\x0d\x0a1、对设早岩裤备初始化和释放；\x0d\x0a\x0d\x0a2、把数据从内核传送到硬件和从硬件读取数据；\x0d\x0a\x0d\x0a3、读取应用程序传送给设备文件的数据和回送应用程序请求的数据；\x0d\x0a\x0d\x0a4、检测和处理设备出现的错误。\x0d\x0a\x0d\x0a在Linux *** 作系统下有三类主要的设备文件类型，一是字符设备，二是块设备，三是网络设备。字符设备和块设备的主要区别是:在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如果不能，就调用请求函数来进行实际的I/O *** 作。块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来陆简等待。\x0d\x0a\x0d\x0a已经提到，用户进程是通过设备文件来与实际的硬件打交道。每个设备文件都都有其文件属性(c/b)，表示是字符设备还是块设备?另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们。设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序。\x0d\x0a\x0d\x0a最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度。也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作。如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck。\x0d\x0a\x0d\x0a二、实例剖析\x0d\x0a\x0d\x0a我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。把下面的C代码输入机器，你就会获得一个真正的设备驱动程序。\x0d\x0a\x0d\x0a由于用户进程是通过设备文件同硬件打交道，对设备文件的 *** 作方式不外乎就是一些系统调用，如 open，read，write，close?， 注意，不是fopen， fread，但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据结构：\x0d\x0a\x0d\x0aSTruct file_operatiONs {\x0d\x0a\x0d\x0aint (*seek) (struct inode * ，struct file *， off_t ，int)\x0d\x0a\x0d\x0aint (*read) (struct inode * ，struct file *， char ，int)\x0d\x0a\x0d\x0aint (*write) (struct inode * ，struct file *， off_t ，int)\x0d\x0a\x0d\x0aint (*readdir) (struct inode * ，struct file *， struct dirent * ，int)\x0d\x0a\x0d\x0aint (*select) (struct inode * ，struct file *， int ，select_table *)\x0d\x0a\x0d\x0aint (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long)\x0d\x0a\x0d\x0aint (*mmap) (struct inode * ，struct file *， struct vm_area_struct *)\x0d\x0a\x0d\x0aint (*open) (struct inode * ，struct file *)\x0d\x0a\x0d\x0aint (*release) (struct inode * ，struct file *)\x0d\x0a\x0d\x0aint (*fsync) (struct inode * ，struct file *)\x0d\x0a\x0d\x0aint (*fasync) (struct inode * ，struct file *，int)\x0d\x0a\x0d\x0aint (*check_media_change) (struct inode * ，struct file *)\x0d\x0a\x0d\x0aint (*revalidate) (dev_t dev)\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0a这个结构的每一个成员的名字都对应着一个系统调用。用户进程利用系统调用在对设备文件进行诸如read/write *** 作时，系统调用通过设备文件的主设备号找到相应的设备驱动程序，然后读取这个数据结构相应的函数指针，接着把控制权交给该函数。这是linux的设备驱动程序工作的基本原理。既然是这样，则编写设备驱动程序的主要工作就是编写子函数，并填充file_operations的各个域。\x0d\x0a\x0d\x0a下面就开始写子程序。\x0d\x0a\x0d\x0a#include 基本的类型定义\x0d\x0a\x0d\x0a#include 文件系统使用相关的头文件\x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0aunsigned int test_major = 0\x0d\x0a\x0d\x0astatic int read_test(struct inode *inode，struct file *file，char *buf，int count)\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aint left用户空间和内核空间\x0d\x0a\x0d\x0aif (verify_area(VERIFY_WRITE，buf，count) == -EFAULT )\x0d\x0a\x0d\x0areturn -EFAULT\x0d\x0a\x0d\x0afor(left = count left >0 left--)\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0a__put_user(1，buf，1)\x0d\x0a\x0d\x0abuf++\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0areturn count\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0a这个函数是为read调用准备的。当调用read时，read_test()被调用，它把用户的缓冲区全部写1。buf 是read调用的一个参数。它是用户进程空间的一个地址。但是在read_test被调用时，系统进入核心态。所以不能使用buf这个地址，必须用__put_user()，这是kernel提供的一个函数，用于向用户传送数据。另外还有很多类似功能的函数。请参考，在向用户空间拷贝数据之前，必须验证buf是否可用。这就用到函数verify_area。为了验证BUF是否可以用。\x0d\x0a\x0d\x0astatic int write_test(struct inode *inode，struct file *file，const char *buf，int count)\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0areturn count\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0astatic int open_test(struct inode *inode，struct file *file )\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aMOD_INC_USE_COUNT模块计数加以，表示当前内核有个设备加载内核当中去\x0d\x0a\x0d\x0areturn 0\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0astatic void release_test(struct inode *inode，struct file *file )\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aMOD_DEC_USE_COUNT\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0a这几个函数都是空 *** 作。实际调用发生时什么也不做，他们仅仅为下面的结构提供函数指针。\x0d\x0a\x0d\x0astruct file_operations test_fops = {?\x0d\x0a\x0d\x0aread_test，\x0d\x0a\x0d\x0awrite_test，\x0d\x0a\x0d\x0aopen_test，\x0d\x0a\x0d\x0arelease_test，\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0a设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(modules)，如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能动态的卸载，不利于调试，所以推荐使用模块方式。\x0d\x0a\x0d\x0aint init_module(void)\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aint result\x0d\x0a\x0d\x0aresult = register_chrdev(0， "test"， &test_fops)对设备 *** 作的整个接口\x0d\x0a\x0d\x0aif (result \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0amain()\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aint testdev\x0d\x0a\x0d\x0aint i\x0d\x0a\x0d\x0achar buf[10]\x0d\x0a\x0d\x0atestdev = open("/dev/test"，O_RDWR)\x0d\x0a\x0d\x0aif ( testdev == -1 )\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aprintf("Cann't open file \n")\x0d\x0a\x0d\x0aexit(0)\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0aread(testdev，buf，10)\x0d\x0a\x0d\x0afor (i = 0i 回答于 2022-11-18

---