求助 关于MIPS R4000中Linux 中的微型汇编器问题？

xinxincaijq

最近试图修改Linux中的TLB refile 异常处理代码，通过内核代码中提供的UASM汇编器来完成。不过遇到一点标号处理的问题，一直没太想清楚TLB refile异常中对于标号（条件跳转）的处理 好似不正常啊，特别是跟TLB load/store/modify 中对于条件跳转时的标号处理不相同唉。现在贴出编译后的异常程序汇编代码做对比：
TLB refile handler:

0xffffffffc03b08c0 <tlb_handler>: dmfc0 k0,c0_badvaddr0xffffffffc03b08c4 <tlb_handler+4>: dsrl32 k1,k0,0x80xffffffffc03b08c8 <tlb_handler+8>: bnez k1,0xffffffffc03b08cc <tlb_handler+12>0xffffffffc03b08cc <tlb_handler+12>: lui k1,0xc03b0xffffffffc03b08d0 <tlb_handler+16>: ld k1,26016(k1)0xffffffffc03b08d4 <tlb_handler+20>: dsrl k0,k0,0x1b0xffffffffc03b08d8 <tlb_handler+24>: andi k0,k0,0x1ff80xffffffffc03b08dc <tlb_handler+28>: daddu k1,k1,k00xffffffffc03b08e0 <tlb_handler+32>: dmfc0 k0,c0_badvaddr0xffffffffc03b08e4 <tlb_handler+36>: ld k1,0(k1)0xffffffffc03b08e8 <tlb_handler+40>: dsrl k0,k0,0x120xffffffffc03b08ec <tlb_handler+44>: andi k0,k0,0xff80xffffffffc03b08f0 <tlb_handler+48>: daddu k1,k1,k00xffffffffc03b08f4 <tlb_handler+52>: dmfc0 k0,c0_xcontext0xffffffffc03b08f8 <tlb_handler+56>: ld k1,0(k1)0xffffffffc03b08fc <tlb_handler+60>: andi k0,k0,0xff00xffffffffc03b0900 <tlb_handler+64>: daddu k1,k1,k00xffffffffc03b0904 <tlb_handler+68>: ld k0,0(k1)0xffffffffc03b0908 <tlb_handler+72>: ld k1,8(k1)0xffffffffc03b090c <tlb_handler+76>: dsrl k0,k0,0x60xffffffffc03b0910 <tlb_handler+80>: dsrl k1,k1,0x60xffffffffc03b0914 <tlb_handler+84>: mtc0 k0,c0_entrylo00xffffffffc03b0918 <tlb_handler+88>: mtc0 k1,c0_entrylo10xffffffffc03b091c <tlb_handler+92>: ehb0xffffffffc03b0920 <tlb_handler+96>: tlbwr0xffffffffc03b0924 <tlb_handler+100>: ld k0,-32520(zero)0xffffffffc03b0928 <tlb_handler+104>: eret0xffffffffc03b092c <tlb_handler+108>: bgez k0,0xffffffffc03b0930 <tlb_handler+112>0xffffffffc03b0930 <tlb_handler+112>: dsll32 k1,k0,0x40xffffffffc03b0934 <tlb_handler+116>: bgez k1,0xffffffffc03b0938 <tlb_handler+120>0xffffffffc03b0938 <tlb_handler+120>: lui k1,0xc8000xffffffffc03b093c <tlb_handler+124>: dsubu k0,k0,k10xffffffffc03b0940 <tlb_handler+128>: lui k1,0xc0370xffffffffc03b0944 <tlb_handler+132>: b 0xffffffffc03b0948 <tlb_handler+136>0xffffffffc03b0948 <tlb_handler+136>: addiu k1,k1,-245760xffffffffc03b094c <tlb_handler+140>: lui k1,0xc4000xffffffffc03b0950 <tlb_handler+144>: dsubu k0,k0,k10xffffffffc03b0954 <tlb_handler+148>: lui k1,0xc0370xffffffffc03b0958 <tlb_handler+152>: b 0xffffffffc03b095c <tlb_handler+156>0xffffffffc03b095c <tlb_handler+156>: addiu k1,k1,-327680xffffffffc03b0960 <tlb_handler+160>: j 0xffffffffc0049ea0 <tlb_do_page_fault_0>0xffffffffc03b0964 <tlb_handler+164>: nop0xffffffffc03b0968 <tlb_handler+168>: nop0xffffffffc03b096c <tlb_handler+172>: nop0xffffffffc03b0970 <tlb_handler+176>: nop 在<tlb_handler+ 8>,<tlb_hander+108>,<tlb_hanlder+116> 位置的跳转代码很诡异啊，这个不像是条件跳转指令的汇编代码吧。他们对应在build_tlb_refile_handler()中的代码如果没有出错到话应该是：uasm_il_bnez(p, r, ptr, label_module_alloc);  注意这个标号-label_module_alloc,uasm_il_bgez(p, r, ptr, label_vmalloc);注意这个标号-label_vmalloc;  这两个标号对应到上面汇编代码中的两个条件跳转中，感觉总是不对啊。如果你对比一下下面的TLB_load handler则会感觉更明显一些： 0xffffffffc0396000 <handle_tlbl>: dmfc0 k0,c0_badvaddr0xffffffffc0396004 <handle_tlbl+4>: dsrl32 k1,k0,0x80xffffffffc0396008 <handle_tlbl+8>: bnez k1,0xffffffffc0396098 <handle_tlbl+152>0xffffffffc039600c <handle_tlbl+12>: lui k1,0xc03b0xffffffffc0396010 <handle_tlbl+16>: ld k1,30112(k1)0xffffffffc0396014 <handle_tlbl+20>: dsrl k0,k0,0x1b0xffffffffc0396018 <handle_tlbl+24>: andi k0,k0,0x1ff80xffffffffc039601c <handle_tlbl+28>: daddu k1,k1,k00xffffffffc0396020 <handle_tlbl+32>: dmfc0 k0,c0_badvaddr0xffffffffc0396024 <handle_tlbl+36>: ld k1,0(k1)0xffffffffc0396028 <handle_tlbl+40>: dsrl k0,k0,0x120xffffffffc039602c <handle_tlbl+44>: andi k0,k0,0xff80xffffffffc0396030 <handle_tlbl+48>: daddu k1,k1,k00xffffffffc0396034 <handle_tlbl+52>: dmfc0 k0,c0_badvaddr0xffffffffc0396038 <handle_tlbl+56>: ld k1,0(k1)0xffffffffc039603c <handle_tlbl+60>: dsrl k0,k0,0x90xffffffffc0396040 <handle_tlbl+64>: andi k0,k0,0xff80xffffffffc0396044 <handle_tlbl+68>: daddu k1,k1,k00xffffffffc0396048 <handle_tlbl+72>: ld k0,0(k1)0xffffffffc039604c <handle_tlbl+76>: tlbp0xffffffffc0396050 <handle_tlbl+80>: andi k0,k0,0x30xffffffffc0396054 <handle_tlbl+84>: xori k0,k0,0x30xffffffffc0396058 <handle_tlbl+88>: bnez k0,0xffffffffc03960c8 <handle_tlbl+200>0xffffffffc039605c <handle_tlbl+92>: ld k0,0(k1)0xffffffffc0396060 <handle_tlbl+96>: ori k0,k0,0x880xffffffffc0396064 <handle_tlbl+100>: sd k0,0(k1)0xffffffffc0396068 <handle_tlbl+104>: ori k1,k1,0x80xffffffffc039606c <handle_tlbl+108>: xori k1,k1,0x80xffffffffc0396070 <handle_tlbl+112>: ld k0,0(k1)0xffffffffc0396074 <handle_tlbl+116>: ld k1,8(k1)0xffffffffc0396078 <handle_tlbl+120>: dsrl k0,k0,0x60xffffffffc039607c <handle_tlbl+124>: dsrl k1,k1,0x60xffffffffc0396080 <handle_tlbl+128>: mtc0 k0,c0_entrylo00xffffffffc0396084 <handle_tlbl+132>: mtc0 k1,c0_entrylo10xffffffffc0396088 <handle_tlbl+136>: ehb0xffffffffc039608c <handle_tlbl+140>: tlbwi0xffffffffc0396090 <handle_tlbl+144>: ld k0,-32520(zero)0xffffffffc0396094 <handle_tlbl+148>: eret0xffffffffc0396098 <handle_tlbl+152>: dsll32 k1,k0,0x40xffffffffc039609c <handle_tlbl+156>: bgez k1,0xffffffffc03960b4 <handle_tlbl+180>0xffffffffc03960a0 <handle_tlbl+160>: lui k1,0xc8000xffffffffc03960a4 <handle_tlbl+164>: dsubu k0,k0,k10xffffffffc03960a8 <handle_tlbl+168>: lui k1,0xc0370xffffffffc03960ac <handle_tlbl+172>: b 0xffffffffc0396014 <handle_tlbl+20>0xffffffffc03960b0 <handle_tlbl+176>: addiu k1,k1,-245760xffffffffc03960b4 <handle_tlbl+180>: lui k1,0xc4000xffffffffc03960b8 <handle_tlbl+184>: dsubu k0,k0,k10xffffffffc03960bc <handle_tlbl+188>: lui k1,0xc0370xffffffffc03960c0 <handle_tlbl+192>: b 0xffffffffc0396014 <handle_tlbl+20>0xffffffffc03960c4 <handle_tlbl+196>: addiu k1,k1,-327680xffffffffc03960c8 <handle_tlbl+200>: j 0xffffffffc0049ea0 <tlb_do_page_fault_0>0xffffffffc03960cc <handle_tlbl+204>: nop0xffffffffc03960d0 <handle_tlbl+208>: nop0xffffffffc03960d4 <handle_tlbl+212>: nop 看了上面的TLB load handler异常处理代码，其中的  0xffffffffc0396008 <handle_tlbl+8>: bnez k1,0xffffffffc0396098 <handle_tlbl+152>0xffffffffc039600c <handle_tlbl+12>: lui k1,0xc03b。。。。0xffffffffc0396058 <handle_tlbl+88>: bnez k0,0xffffffffc03960c8 <handle_tlbl+200>0xffffffffc039605c <handle_tlbl+92>: ld k0,0(k1)。。。。。0xffffffffc039609c <handle_tlbl+156>: bgez k1,0xffffffffc03960b4 <handle_tlbl+180>0xffffffffc03960a0 <handle_tlbl+160>: lui k1,0xc800.。。。。。感觉这样的条件跳转代码才正常吧，注意是+152，+200，+180。而不是像在下面的 TLB refile handler 中的这样的+12 ，+112，如果是这样到话不等于没有条件跳转么？0xffffffffc03b08c8 <tlb_handler+8>: bnez k1,0xffffffffc03b08cc <tlb_handler+12>0xffffffffc03b08cc <tlb_handler+12>: lui k1,0xc03b。。。。。。0xffffffffc03b0928 <tlb_handler+104>: eret0xffffffffc03b092c <tlb_handler+108>: bgez k0,0xffffffffc03b0930 <tlb_handler+112>0xffffffffc03b0930 <tlb_handler+112>: dsll32 k1,k0,0x4.。。。。。。。 我感觉是不是在TLB refile handler中的标号重定位不正确吧，可是明明这样的异常处理程序是正常工作的，表示很不解，求高人解答。我因为最近试图修改TLB refile handler，想在其中添加一些 条件跳转指令代码，可是发现老是不能正常工作，于是去查看汇编器生成的异常处理程序，发现跟标号有关的条件跳转指令不正常，于是就去查看原版的TLB refile handler 发现条件跳转指令很诡异啊，越发看不明白了。这些TLB 异常处理二进制代码是通过 GDB 的X 命令反汇编出来的，分别来自  linux/MIPS 内核中的tlb_handler，handle_tlbl,handle_tlbs,handle_tlbm 标号处，不知到这个方法看到的异常处理程序是否正确呢？ 另外 ，我使用gdb调试内核时候，单步跟踪异常处理程序必须使用 k0，k1两个寄存器，而TLB refile/load/store/modify 的快速异常处理程序中仅仅使用了k0，k1 两个寄存器，这样就产生了冲突。请问有什么办法能使gdb可以单步调试tlb 的几个相关的异常处理程序，清楚的看到跟随某个指令后寄存器值的变化情况？