3.4.43內核 init_post panic 求教

alexhak2004

最近剛接觸內核移植方面的工作，把3.4.43內核移植到arm1176上的時候，在調用init_post的時候，出現(xiàn)了panic的現(xiàn)象。經過分析，發(fā)現(xiàn)是由于
run_init_process調用失敗導致，具體的調用鏈如下：

run_init_process->kernel_execve->do_execve->search_binary_handler->load_elf_binary->padzero->__clear_user_std，
__clear_user_std傳過來的參數(shù)總共有兩個，一個是地址0xAB7C2，一個是數(shù)量0x83e，當執(zhí)行匯編“strbt r2, [r0], #1”后，跳轉到
data abort的異常了。

個人覺得，該函數(shù)的本意是清除一段user space的內存，應該不存在權限的問題，那么出現(xiàn)data abort的異常，應該是對應的頁表還沒有生成出來。

問題如下：
1.在調用__clear_user_std的時候，用戶空間的頁表是否應該已經創(chuàng)建出來？
2.如果創(chuàng)建出來了，創(chuàng)建的對應調用在哪里？

第一次做移植工作，所以可能問的問題比較弱，請不吝賜教。

humjb_1983

地址有點奇怪~
內核態(tài)訪問的用戶態(tài)的地址必須是已經有頁表映射的，否則就會異常~
用戶態(tài)虛擬地址的頁表通常是通過缺頁異常進行映射的。。。

alexhak2004

感謝回復，又仔細debug了一下代碼，發(fā)現(xiàn)問題，但是還是覺得奇怪。

現(xiàn)在初步的結論是由于data abort后返回的地址不對，引起data abort的指令沒有能夠正常執(zhí)行，
所以導致返回值判斷出錯。

繼續(xù)上一帖子，說明一下我看到的執(zhí)行流程。

1.在地址 0xc0109078處（屬于函數(shù)__clear_user_std，函數(shù)的返回地址在0xc00d2ac8），存在指令“strbt r2, [r0], #1”，
此時SP_SVC=0xc482be58，

2.在執(zhí)行這條指令后，產生data_dataabort異常，切換到dabt模式，此時SP_DABT=0xc0ed288c，而引起異常的指令地址
0xc0109078被存到了dataabort模式下的棧中0xc0ed2890=0xc0109078

3.程序跳轉到vector_dabt，最后跳轉到__dabt_svc，由于最后是通過"movs pc, lr"進行跳轉的，所以進行了狀態(tài)切換，又
切換到了SVC模式，此時的SP_SVC為0xC482BE58。在__dabt_svc中，首先保存了r1~r12，接下來，由于r0剛好指向了
dabt模式下的棧，所以"LDM r0, {r3-r5}"，使得r3保存了__clear_user_std中的線性地址，r4保存了出錯指令地址，r5保存
了之前SVC的處理器CPSR（=0x60000013）。此時lr=0xc00d2AC8，剛好是__clear_user_std的返回地址。
4.調用v6_early_abort->do_DataAbort進行處理，沒有錯誤

5.函數(shù)返回后，最后通過ldmib sp, {r1-r15}跳到 “pop {p0,pc}”

問題是，此時SP為0xc482be58，還是屬于SVC模式的棧，并沒有回到DABT模式的棧，所以，PC回到了0xc00d2ac8，而不是
出錯指令地址0xc0109078，并沒有重新執(zhí)行，所以這會引起后面的判斷失敗�，F(xiàn)在不知道應該如何處理。。。






回復 2# humjb_1983


   

alexhak2004

感覺應該先切換到DABT模式才能夠拿到錯誤指令地址。。。

alexhak2004

和原始的3.4.43的內核進行了對比，沒有發(fā)現(xiàn)差異，糾結了

alexhak2004

和原始的3.4.43的內核進行了對比，沒有發(fā)現(xiàn)差異，糾結了

linuxfellow

編譯器用的是哪個版本？ 我用GCC4.8.3編譯arm時就有問題，找到補丁才解決問題