《VxWorks任务追踪实例分析》由会员分享，可在线阅读，更多相关《VxWorks任务追踪实例分析（3页珍藏版）》请在金锄头文库上搜索。
1、VxWorks 任务追踪实例分析 (zz) VxWorks 中如果稍有不慎，就可能导致 task suspend，如果运气好， shell 没有被挂起，则可以通过系统的一些命令追踪一下挂起的原因。其中用到的主要命令是 i、 tt、 ti、 d 等。 首先从出错信息开始： 0xfc8125b8 (t_Lcd): memPartFree: invalid block 0xfdfc6f38 in partition 0xfe508894. 由于 memPartFree 了一个非法的内存块，导致了任务挂起，我们需要确定到底是哪条语句导致了这个异常的产生，可能是什么原因引起的。 首先，需要通过 “i”命
2、令察看任务状态： - i NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY - - - - - - - - - tExcTask excTask fdffec80 0 PEND fe3c5f50 fdffeb60 3006b 0 tLogTask logTask fdffc298 0 PEND fe3c5f50 fdffc188 0 0 tShell shell fdf5fa48 1 READY fe1f3afc fdf5f628 0 0 t_Lcd fe392a30 fc8125b8 100 SUSPEND fe1f24b0 fc8120b8 d0003
3、 0 可以看到任务 t_Lcd 的状态为 SUSPEND，即被挂起的状态。其他各项的含义都比较清楚， ENTRY是任务的入口函数，如果没有 symbol，则直接显示地址， TID 是任务的 ID 号，一般用任务的栈底地址表示， PC 是当前的指令位置， SP 是当前栈顶位置。 然后通过 ”tt”来追溯函数调用过程： - tt t_Lcd fe3c14f4 vxTaskEntry +68 : fe392a30 () fe392b48 initLcdComponent+2e8: fe392bdc () fe392bec initLcdComponent+38c: fe392bfc () fe393
4、33c initLcdComponent+adc: lcdShowPassWord () fe398590 lcdShowPassWord+84 : saveModifiedSetting () fe3a3790 saveModifiedSetting+220: saveSettingValue (1) fe1fd6d0 saveSettingValue+148: fe1fc428 (0, 5, ffffffff) fe1fc888 getDeviceSettingValue+64c: fclose () fe1aab48 fclose +ec : free () fe1bb7d4 free
5、+1c : memPartFree () fe1bb2dc memPartFree +148: taskSuspend () 我们可以了解到函数的调用过程， vxTaskEntry()?-fe392a30()-fe392bdc ()-fe392bfc ()-lcdShowPassWord ()-saveModifiedSetting ()-saveSettingValue (1)-fe1fc428 (0, 5, ffffffff)-fclose ()-free ()-memPartFree ()-taskSuspend ()。 其他相关信息： 第一栏是发生跳转（即函数调用）后的返回地址，稍后会
6、作详细解释， 第二栏是离返回地址最近的 symbol 和偏移量，一般情况下会是发 起调用的那个函数的名称，除非该函数是内部函数，系统中没有 symbol， 第三栏是被调用的函数。 再来查看一下 t_Lcd 任务的栈里的内容，从前面的任务信息里已经得知当前栈顶位置为 fc8120b8，通过 “d”命令显示该地址的内容。 - d 0xfc8120b0 fc8120b0: fc81 25b8 fc81 25b8 fc81 20c8 fe1f 24b0 *.%.%. .$.* fc8120c0: fe50 8894 fdfc 6f30 fc81 20e8 fe1b b2dc *.P.o0. .* fc
7、8120d0: fdf2 6b08 0000 0100 0000 000c 0000 0000 *.k.* fc8120e0: 0000 0000 fdf1 ed80 fc81 20f8 fe1b b7d4 *. .* fc8120f0: fd9a 3538 fdf1 ed80 fc81 2108 fe1a ab48 *.58.!.H* fc812100: fd9a 3538 fc81 2108 fc81 2238 fe1f c888 *.58.!.8.* fc812110: 0000 0000 0000 0005 ffff ffff 0000 0600 *.* fc812120: 0000
8、000a fdf1 ed80 4230 312e 7874 6373 *.B01.xtcs* fc812130: 5f62 7566 2e69 6c32 0000 0000 0000 0000 *_buf.il2.* 这里我们可以看到一些熟悉的地址，注意看最后两列，在这里可以找到 ”tt”中显示的第一栏地址即函数调用的返回地址。两个返回地址之间是该函数的栈空间，用于保存栈指针、局部变量或者相关寄存器的值。要具体了解这些值是怎么来的，就要用到反汇编了。 反汇编通过 objdump 命令来实现，不同类型的 cpu 会有不同的可执行文件，例如： objdumpppc -D vxworks xx.s
9、反汇编的结果可能会很大，耐心等待吧。我们来看一下 fclose()里调用 free()的这一过程，在汇编代码里查找返回地址 fe1aab48。 fe1aaa5c : fe1aab44: 48 01 0c 75 bl fe1bb7b8 fe1aab48: 38 00 00 00 li r0,0 bl 是无条件跳转指令， free()执行完之后，应返回 fe1aab48 继续执行。 查找 fe1bb7b8，看看 free 被调用时干了些什么？ fe1bb7b8 : fe1bb7b8: 94 21 ff f0 stwu r1,-16(r1) fe1bb7bc: 7c 08 02 a6 mflr r0
10、 fe1bb7c0: 90 01 00 14 stw r0,20(r1) fe1bb7c4: 7c 64 1b 78 mr r4,r3 fe1bb7c8: 3c 60 fe 51 lis r3,-431 fe1bb7cc: 38 63 88 94 addi r3,r3,-30572 fe1bb7d0: 4b ff f9 c5 bl fe1bb194 fe1bb7d4: 80 01 00 14 lwz r0,20(r1) fe1bb7d8: 7c 08 03 a6 mtlr r0 fe1bb7dc: 38 21 00 10 addi r1,r1,16 fe1bb7e0: 4e 80 00 20
11、blr 虽然不同类型 cpu 的汇编指令不同，但还是可以大致猜出其中的含义。 stwu 指令将 r1 保存到地址 (r1-16)位置，然后让将 r1 减去 16 保存到 r1 中，完成了保存并更新栈指针的过程；第 2、 3 条语句将返回地址保存到 r1+20 的 位置；下面几条语句实际上是准备参数的过程， r3,r4 一般用来保存函数的形参值，随后调用了 memPartFree。从 memPartFree 返回后， 先从堆栈上读取返回地址，然 后将栈顶下移 16字节，即恢复到原来的位置，最后跳转到返回地址。 对着内存内容校验一下， fclose 调用 free 后的返回地址为 fe1aab48
12、，按照上面的分析，这个地址会被free()函数保存在 r1+20 的位置，因此 r1+20=fc8120fc， r1=fc8120e8，而 free 中将 r1 减去了 16，所以刚进入 free()时， r1 应该等于 fc8120f8，这个数值会被保存在 fc8120e8 处，事实正是如此。 这里栈内空间的利用有点交叉混杂，暂时没有弄的太明白，并且 free()中没有用到过 fc8120f0-fc8120f8空间的内存，推测可能是栈的大小至少为 16 字节所以留空了，里面的内容是历史遗留产物，是否如此，还有待进一步的研究。 以上是比较通用的分析过程，本来还涉及到结合 c 代码的分析，跟具体的例子结合太紧密，就不赘述了，有一点可以提一下，想追溯函数调用过程中某一参数 的运行值，可能会在调用者的栈中，也可能会在调用者的调用者的栈中，这个需要结合具体的汇编码来分析。因为函数的栈开辟出来是为了保存一些临时的乱七八糟 的东西，比如需要用到 r38，就会把 r38 临时保存到栈上，返回时再恢复。而对本函数有用的变量，通常会 被优化到寄存器中保存，除非寄存器不够用了，才会 用到栈空间。 发觉 debug 有时跟探案一样好玩。
