上章鏈接入口: http://www.cnblogs.com/lifexy/p/8006748.html 在上章里,我們分析了oops的PC值在哪個函數出錯的 本章便通過棧信息來分析函數調用過程 1.上章的oops棧信息如下圖所示: 9fe0: 代表最初的棧頂SP寄存器位置 9e80:代表函數出錯的 ...
上章鏈接入口: 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();
