浅析vxWorks系统中如何抓取任务的函数调用轨迹.docVIP

这几天连续查了几个关于死机、网口死的问题，情况基本上都是任务吊死了，包括大家有时看到的串口和网口都不响应，也往往都是由于任务停止切换而造成的。对于这类问题，我们一般感觉比较棘手，因为一旦网口串口全都拒绝响应之后，整个系统对于我们来说就是一个黑盒了， 程序员坐在显示器前边，只能束手无策望洋兴叹。这里结合我自己的一些经验和所知，试图为大家寻找到一种处理类似问题的思路，希望能够对大家有所帮助。 其实大家都曾经看到过操作系统模块里边os_exc.c这个文件，但许多人并不知道它能够完成的真正功能和工作原理，要弄清楚这些，我们必须先初步了解一下vxWorks系统在函数调用过程中的一些底层实现机制，看看我们如何抓到指定任务的函数调用轨迹的，因为吃透了这些，我们就可以在必要的时候，抓取指定任务的函数调用栈，从而基本可以定位处任务吊死在哪个函数内部了。 首先，PPC有32个通用寄存器(GPRS)和7个专用寄存器(SPRS)，这里，作为上层软件的开发人员，大家并不需要去深入了解过多的操作系统细节，也无需对CPU的每个寄存器每根线都了如指掌，而只需将注意力集中在我们所关心的通用寄存器gpr1、gpr3以及专用寄存器lr、pc。它们的重要性是因为：在函数调用过程中，gpr1就是sp，也就是函数的堆栈指针，gpr3是函数调用过程中传参的第一个寄存器（函数实参从gpr3开始顺序存放，如果寄存器放不下了，就会压入堆栈，然后执行跳转指令进入被调用函数，被调用函数再从这些事先约定的寄存器中取出实参进行后续处理，同样，函数的返回值也是存放在r3中的），lr是函数调用过程中的返回指令地址（也就是函数调用点的下一条指令地址），而pc是当前指令地址。 上边的说法可能比较抽象，有些不便于理解，那么我们看下边这个例子代码的汇编结果： int myfunc2(int i) { int j; j = 0; j += i; return j; } int myfunc1() { int i; int j; i = 4 *5; j = myfunc2(i); return j; } 相应的汇编代码如下，莫为乱花迷了眼，我们只需关注红色部分即可： int myfunc1() { 0x167b4 myfunc1: stwu r1, 0xffe8(r1) 0x167b8 +0x004: mfspr r0, LR 0x167bc +0x008: stw r31, 0x14(r1) 0x167c0 +0x00c: stw r0, 0x1c(r1) 0x167c4 +0x010: or r31, r1, r1 int i; int j; i = 4 *5; 0x167c8 +0x014: li r0, 0x14 (20) 0x167cc +0x018: stw r0, 0x8(r31) j = myfunc2(i); 0x167d0 +0x01c: lwz r3, 0x8(r31) 0x167d4 +0x020: bl myfunc2 0x167d8 +0x024: or r0, r3, r3 0x167dc +0x028: stw r0, 0xc(r31) return j; 0x167e0 +0x02c: lwz r3, 0xc(r31) 0x167e4 +0x030: b myfunc1 + 0x34 } 0x167e8 +0x034: lwz r11, 0x0(r1) 0x167ec +0x038: lwz r0, 0x4(r11) 0x167f0 +0x03c: mtspr LR, r0 0x167f4 +0x040: lwz r31, 0xfffc(r11) 0x167f8 +0