上章鏈接入口:?http://www.cnblogs.com/lifexy/p/8006748.html

在上章里,我們分析了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

?

... ...(此處省略n字)

4.最終分析出,棧信息的調用過程如下:

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

?

轉載于:https://www.cnblogs.com/lifexy/p/8011966.html

總結

以上是生活随笔為你收集整理的37.Linux驱动调试-根据oops的栈信息,确定函数调用过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。