VxWorks任务追踪实例分析

VxWorks中如果稍有不慎，就可能导致task suspend，如果运气好，shell没有被挂起，则可以通过系统的一些命令追踪一下挂起的原因。其中用到的主要命令是i、tt、ti、d等。

首先从出错信息开始：

0xfc8125b8 (t_Lcd): memPartFree: invalid block 0xfdfc6f38 in partition 0xfe508894.

由于memPartFree了一个非法的内存块，导致了任务挂起，我们需要确定到底是哪条语句导致了这个异常的产生，可能是什么原因引起的。

首先，需要通过“i”命令察看任务状态：

-> 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 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 () 

fe39333c 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 +1c : memPartFree () 

fe1bb2dc memPartFree +148: taskSuspend ()

我们可以了解到函数的调用过程，vxTaskEntry()?->fe392a30()->fe392bdc ()->fe392bfc ()->lcdShowPassWord ()->saveModifiedSetting ()->saveSettingValue (1)->fe1fc428 (0, 5, ffffffff)->fclose ()->free ()->memPartFree ()->taskSuspend ()。

其他相关信息：

第一栏是发生跳转（即函数调用）后的返回地址，稍后会作详细解释，

第二栏是离返回地址最近的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.. .....* fc8120d0: 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 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

反汇编的结果可能会很大，耐心等待吧。我们来看一下fclose()里调用free()的这一过程，在汇编代码里查找返回地址fe1aab48。

fe1aaa5c <fclose>: …… fe1aab44: 48 01 0c 75 bl fe1bb7b8 <free> fe1aab48: 38 00 00 00 li r0,0

bl是无条件跳转指令，free()执行完之后，应返回fe1aab48继续执行。

查找fe1bb7b8，看看free被调用时干了些什么？

fe1bb7b8 <free>: fe1bb7b8: 94 21 ff f0 stwu r1,-16(r1) fe1bb7bc: 7c 08 02 a6 mflr r0 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 <memPartFree> 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 blr

虽然不同类型cpu的汇编指令不同，但还是可以大致猜出其中的含义。stwu指令将r1保存到地址(r1-16)位置，然后让将r1减去16保存到r1中，完成了保存并更新栈指针的过程；第2、3条语句将返回地址保存到r1+20的 位置；下面几条语句实际上是准备参数的过程，r3,r4一般用来保存函数的形参值，随后调用了memPartFree。从memPartFree返回后， 先从堆栈上读取返回地址，然后将栈顶下移16字节，即恢复到原来的位置，最后跳转到返回地址。

对着内存内容校验一下，fclose调用free后的返回地址为fe1aab48，按照上面的分析，这个地址会被free()函数保存在r1+20 的位置，因此r1+20=fc8120fc，r1=fc8120e8，而free中将r1减去了16，所以刚进入free()时，r1应该等于 fc8120f8，这个数值会被保存在fc8120e8处，事实正是如此。

这里栈内空间的利用有点交叉混杂，暂时没有弄的太明白，并且free()中没有用到过fc8120f0-fc8120f8空间的内存，推测可能是栈的大小至少为16字节所以留空了，里面的内容是历史遗留产物，是否如此，还有待进一步的研究。

以上是比较通用的分析过程，本来还涉及到结合c代码的分析，跟具体的例子结合太紧密，就不赘述了，有一点可以提一下，想追溯函数调用过程中某一参数 的运行值，可能会在调用者的栈中，也可能会在调用者的调用者的栈中，这个需要结合具体的汇编码来分析。因为函数的栈开辟出来是为了保存一些临时的乱七八糟 的东西，比如需要用到r38，就会把r38临时保存到栈上，返回时再恢复。而对本函数有用的变量，通常会被优化到寄存器中保存，除非寄存器不够用了，才会 用到栈空间。

发觉debug有时跟探案一样好玩。