首页 > 系统相关> 文章详细

33.Linux驱动调试-根据oops的栈信息,确定函数调用过程

2021-04-16 16:53:20 阅读：190 来源： 互联网

标签：函数 33 sp 栈顶函数调用 lr 内核 open oops

上章链接入口: https://blog.csdn.net/qq_16933601/article/details/104327937
在上章里,我们分析了oops的PC值在哪个函数出错的

本章便通过栈信息来分析函数调用过程

1.上章的oops栈信息如下图所示:

在这里插入图片描述
9fe0: 代表最初的栈顶SP寄存器位置
9e80:代表函数出错的SP寄存器位置

2.我们先来分析上图的栈信息,又是怎样的过程呢?

2.1内核主要是通过STMDB和LDMIA汇编命令来入栈和出栈

(STMDB和LDMIA汇编命令参考: http://www.cnblogs.com/lifexy/p/7363208.html)

内核每进入一个函数就会通过STMDB,将上个函数的内容值存入栈顶sp,然后栈顶sp-4.

当内核的某个函数出问题时,内核便通过LDMIA,将栈顶sp打印出来,然后栈顶sp+4,直到到达最初的栈顶

2.2我们以下图的3个函数为例:

在这里插入图片描述
若c()函数出问题后,内核就会打印b()函数的内容(0x03,LR), 打印a()函数的内容(0x02,LR),直到sp到达栈顶为止

其中lr值,便代表各个函数的调用关系

3.接下来我们便以上章的oops里的栈信息来分析

在上章里,我们找到PC值bf000078在26th_segmentfault驱动模块first_drv_open()函数下出错。

3.1先来看first_drv_open()函数,找到STMDB入栈的lr值,来确定被哪个函数调用的

在这里插入图片描述
如上图所示，first_drv_open()函数里,通过stmdb sp!, {r4, r5, fp, ip, lr, pc} 存入了6个值,
所以, 返回到上个函数的值lr =c008d888
在上章,我们便分析到:
内核的虚拟地址是c0004000~c03cebf4，所以c008d888位于内核的某个函数里

3.2 然后将内核进行反汇编

在内核源码的根目录下:

# arm-none-linux-gnueabi-objdump -D vmlinux > vmlinux.txt      //-D:反汇编所有段    vmlinux:未压缩的内核

3.3 打开vmlinux.txt

如下图所示,搜索c008d888:
在这里插入图片描述
往上翻,找到c008d888位于函数chrdev_open()下:

如上图所示, chrdev_open()函数存了10个值,所以,返回到上个函数的值lr= c0089e48

3.4 继续搜索c0089e48:

在这里插入图片描述
往上翻,找到c0089e48位于函数__dentry_open ()下:

如上图所示, __dentry_open()函数存了10个值,所以,第二个值lr= c0089f64

3.5 继续搜索c0089f64:

在这里插入图片描述
往上翻,找到c0089f64位于函数nameidata_to_filp()下:

如上图所示, nameidata_to_filp函数存了6个值,所以,第二个值lr= c0089fb8

4.最终分析出,栈信息的调用过程如下:

ret_fast_syscall()->
　　sys_open()->
　　　　 do_sys_open()->
　　　　　　 do_filp_open()->
　　　　　　　　 nameidata_to_filp()->
　　　　　　　　　　 chrdev_open()->
　　　　　　　　　　　　　　first_drv_open();

标签：函数,33,sp,栈顶,函数调用,lr,内核,open,oops
来源： https://blog.51cto.com/u_11934066/2711491

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9