首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

教你如何找到导致程序跑飞的指令(2)

教你如何找到导致程序跑飞的指令(2)

这样,只要发生异常中断就都会进入FaultIsr函数,FaultIsr函数如下:
void FaultIsr()
{
    while(1)
   {
        ;
   }
}
可以看到FaultIsr函数是个死循环,所以当程序发生异常跑飞时就会死在这里了。

准备工作完成,准备实战演练!在这之前还有一点需要注意,那就是最好将编译选项设置为不优化,这样方便我们定位问题。当然,实际情况也许不允许我们这么做,这样的话就需要你有比较高的汇编语言水平了,这不在本文讨论之内,先不管了。我们在这个例子里将编译选项设置为不优化。

我们将上面改动后的代码重新编译,然后加载到单板里,进入仿真状态,然后全速运行,然后再停止运行,我们就可以发现程序死在FaultIsr函数里了,如下图所示:

图1


从图1可以看到程序停在了42行,这与我们的设计是一致的。在图1的左侧显示了此时各个寄存器内的数值,注意到LR寄存器了吧,这里保存的就是返回地址,出错的指令就在这附近。但,还有一点需要注意,FaultIsr函数是C语言函数,它运行时可能会修改LR寄存器,如果是这样的话,那么此时LR寄存器内的数值就不是发生异常时的值了,为解决此问题,我们可以找到FaultIsr函数的起始地址,将断点打在FaultIsr函数的起始地址,这样当异常发生时就会停在断点的地方,也就是FaultIsr函数的起始地址,这样就可以保证LR寄存器的值就是发生异常时的值了。
如果你的汇编语言足够好,那么你可以在图1右上角的汇编窗口里向上找,找到FaultIsr函数的起始地址。另外,我们还可以通过一个简单的方法找到FaultIsr函数的起始地址。我们在keil的选项中选择生成map文件,代码编译后就会生成一个map文件,我们可以从这个文件里找到FaultIsr函数的地址。
使用一个文本编辑器打开这个map文件,然后搜索“FaultIsr”,如下图,我们就找到了FaultIsr函数的起始地址:0x80608

2


在汇编窗口找到0x80608的地址,打上断点,如下图所示:

3


复位程序,再重新全速跑一遍,我们就会发现程序停在了断点上,这时LR里面的数值就是程序异常时存入的返回地址,通过这个地址差不多就可以找到出错的指令了。
如图3所示,LR的值为0x805ec,我们在汇编窗口里跳到这个地址,如下图所示:

4


ARM7内核有2级流水线,存入LR的地址一般会多+8个字节,因此0x805ec-8=0x805e4,如图4所示,0x805e4地址是一条STRB R2[R3]指令,这条指令的意思是将R2寄存器里的数值保存到R3寄存器所指向的地址(一个字节)内。从图3左侧可以看到R2寄存器的数值为0R3寄存器的数值也为0,那么这条指令的意思就是将0这个数值写入0地址这个字节内,这不是正好对应上述main函数中27行的C指令么?
看到这里我们就应该明白了,向0地址写0,这条C指令有问题,那么这个跑飞的问题也就找到原因了,是不是很简单?

当然,实际情况可能要比上述介绍的情况复杂的多。实际使用的程序几乎都是经过优化的,这样从汇编指令找到C指令就会比较麻烦。还有可能FaultIsr函数的指令或者堆栈被破坏了,那么FaultIsr函数运行都会出问题。还有可能出错的指令不会象27行这么明显,可能是经过了前面很多步骤的积累才在这里触发异常的,最典型的就是别人的程序踩了你的内存,结果错误在你的程序里表现出来了,如果遇到这种情况你就先哭一顿吧。对于这种踩内存的情况也是可以通过这种方法定位的,但这相当复杂,需要从出错点开始到触发异常点为止,这之间所有的堆栈信息,然后从最后的堆栈开始,结合反汇编的代码,从最后一条指令向前推,直到发现问题的根源。这种方法相当于是我们用我们的大脑模拟CPU的反向运行过程,如果程序是经过优化的,那么这个过程就更麻烦了。我准备在“底层工作者手册之嵌入式操作系统内核”6.1节实例讲解一个这种情况(现在是2012.02.28,手册暂时只写到了5.4节)。

好了,先不说这么复杂的了,接着上面的继续说。
有时候出现问题的单板并不在我们手边,问题也许不能复现,那么我们就可以预先在FaultIsr函数里做一个打印功能——将出现异常时的寄存器、堆栈、软件版本号等信息打印出来,编写这样的FaultIsr函数需要注意,FaultIsr函数开始的代码一定要用汇编语言来写,以防止调用FaultIsr函数时的寄存器、堆栈信息被C语言破坏。
如果我们的单板有这样的功能,那么当单板跑死时,一般情况都会向外打印信息,比如上面的例子,就会打印出LR的值为0x805ec。但我们似乎又遇到了一个问题,我们如何知道0x805ec这个地址是哪个函数的?别忘了,我们在一个版本发布时会将软件所有的信息归档(什么?没归档!这样的公司我劝你还是走了吧),根据软件版本号找到出问题的软件的归档文件,取出map文件,利用上面讲述的方法通过map文件我们就可以找到出问题的函数了。再通过软件版本从归档文件中找到这个函数最终编译链接生成的目标文件,一般为.o.axf.elf等文件(必须是静态链接的文件,需要有各种段信息的),不能是binhex等文件,windowslinux等动态链接的文件已经超出了我目前的知识范围,也不再其中。
然后使用objdump程序进行反汇编,将目标文件与objdump程序放到同一个目录,在cmd窗口下进到这个目录,执行下面命令:

objdump -d wanlix.elf >> uncode.txt

这行命令的意思是将wanlix.elf目标程序进行反汇编,反汇编的结果以文本格式存入uncode.txt文本文件。
我们用文本编辑器打开uncode.txt文件,找到0x805ec地址,如下图所示:



继承事业,薪火相传
返回列表