3.4.43内核 init_post panic 求教

alexhak2004

最近刚接触内核移植方面的工作，把3.4.43内核移植到arm1176上的时候，在调用init_post的时候，出现了panic的现象。经过分析，发现是由于
run_init_process调用失败导致，具体的调用链如下：

run_init_process->kernel_execve->do_execve->search_binary_handler->load_elf_binary->padzero->__clear_user_std，
__clear_user_std传过来的参数总共有两个，一个是地址0xAB7C2，一个是数量0x83e，当执行汇编“strbt r2, [r0], #1”后，跳转到
data abort的异常了。

个人觉得，该函数的本意是清除一段user space的内存，应该不存在权限的问题，那么出现data abort的异常，应该是对应的页表还没有生成出来。

问题如下：
1.在调用__clear_user_std的时候，用户空间的页表是否应该已经创建出来？
2.如果创建出来了，创建的对应调用在哪里？

第一次做移植工作，所以可能问的问题比较弱，请不吝赐教。

humjb_1983

地址有点奇怪~
内核态访问的用户态的地址必须是已经有页表映射的，否则就会异常~
用户态虚拟地址的页表通常是通过缺页异常进行映射的。。。

alexhak2004

感谢回复，又仔细debug了一下代码，发现问题，但是还是觉得奇怪。

现在初步的结论是由于data abort后返回的地址不对，引起data abort的指令没有能够正常执行，
所以导致返回值判断出错。

继续上一帖子，说明一下我看到的执行流程。

1.在地址 0xc0109078处（属于函数__clear_user_std，函数的返回地址在0xc00d2ac8），存在指令“strbt r2, [r0], #1”，
此时SP_SVC=0xc482be58，

2.在执行这条指令后，产生data_dataabort异常，切换到dabt模式，此时SP_DABT=0xc0ed288c，而引起异常的指令地址
0xc0109078被存到了dataabort模式下的栈中0xc0ed2890=0xc0109078

3.程序跳转到vector_dabt，最后跳转到__dabt_svc，由于最后是通过"movs pc, lr"进行跳转的，所以进行了状态切换，又
切换到了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.函数返回后，最后通过ldmib sp, {r1-r15}跳到 “pop {p0,pc}”

问题是，此时SP为0xc482be58，还是属于SVC模式的栈，并没有回到DABT模式的栈，所以，PC回到了0xc00d2ac8，而不是
出错指令地址0xc0109078，并没有重新执行，所以这会引起后面的判断失败。现在不知道应该如何处理。。。






回复 2# humjb_1983


   

alexhak2004

感觉应该先切换到DABT模式才能够拿到错误指令地址。。。

alexhak2004

和原始的3.4.43的内核进行了对比，没有发现差异，纠结了

alexhak2004

和原始的3.4.43的内核进行了对比，没有发现差异，纠结了

linuxfellow

编译器用的是哪个版本？ 我用GCC4.8.3编译arm时就有问题，找到补丁才解决问题