linux 内核出错信息分析,6.4 必修实验3

内核出错信息分析,6.4 必修实验3"/>

linux 内核出错信息分析,6.4 必修实验3

6.4 必修实验3--内核异常分析(3)

接下来的这些信息，和这个模块的调试没多大关系，它们是虚拟内存页目录、页表信息、oops错误号以及***访问的sysfs文件等。pgd=c39d8000

[00000000] *pgd=339cf031, *pte=00000000, *ppte=00000000

Internal error: Oops: 817 [#1]

last sysfs file: /sys/devices/platform/soc-audio/sound/card0/mixer/dev

Modules linked in: oops(+)

再接下来是寄存器信息，这部分信息比较重要，其中最可能帮助定位错误的寄存器当然是PC。在这部分信息中，下面这句最为关键。

PC is at func_D+0x1c/0x28 [oops]

它直接地告诉了我们，oops出错时，PC是位于func_D函数标号之后的0x1c处(怎么去寻找它？后面会进行分析。另外请思考后面的0x28代表什么？)。

寄存器信息之后是栈信息，但这里还用不上，先略过。

***的部分，也就是Backtrace标号开始的地方，它是oops的精华。它表示回溯信息，也告诉调试者在oops出错之前，模块调用了那些函数。当然，在本实例中，可以看到模块调用了func_D后就出错了，显然错误就在func_D中了。

结尾部分还有一点信息请注意。Code: e59f0010 eb412fb6 e3a0200b e3a03000 (e5832000)

Code标号开始的字段记录了模块出错前***几条机器码，其中被括号括起来的就是oops出错对应的机器码。

(4)根据上面的分析，可以使用反汇编来确定出错的位置。在RHEL5中，使用命令：arm-linux-objdump -D -S oops.ko >log，将模块文件反汇编到log中，使用vim打开该文件log，直接找到func_D标号处，如图6-17所示。

(点击查看大图)图6-17  反汇编结果

根据前面的信息，出错位置应该在func_D+0x1c处，func_D在0x1c，所以出错地址应该是0x38。看看这句汇编代码，前面的语句将寄存器r3赋值为0，然后这句又试图将寄存器r2的值存入到r3指向的地址处，也就是向0地址写。因此出错。再来看看这句出错代码对应的机器码e5832000，显然就是之前在opps的Code字段中看到的被括起来的那个。

(5)通过反汇编程序，定位了汇编代码中的错误位置，但对于用C语言编写的内核模块而言，这样还不够。如何才能准确地定位到C语言中的语句呢？回忆一下在<>中学习gdb调试时，能够在调试中看到对应的源码。当时为了进行gdb调试，在编译时加入了-g选项，这样可以将调试信息加入到目标文件中。由此得到灵感，在这里也加入-g试试。进入实验代码目录2-3-1中的内核源码目录，修改其顶层Makefile，如图6-18所示。

(点击查看大图)图6-18  内核调试信息开关

【责任编辑：云霞 TEL：(010)68476606】

点赞 0