经验与教训(2)－－嵌入式开发随笔（dlmu2001）

2.调试方法和策略
1)断点
很多平台提供了断点调试的功能，这种调试方法比较直观，所以很多开发
人员都过分依赖它。
断点的功能主要包括设置断点，单步执行，更改PC指针，运行到光标处，
查看及修改寄存器或者内存值（watch window，memory window），查看
堆栈，查看汇编代码。有的还可以设置地址断点，条件断点，这在内存越
界的调试的时候非常有用。
应该说，断点调试在开发调试流程中起着很大的作用，但是在断点调试
中也应该多想办法来提高调试的效率，特别是嵌入式系统中，找到一个
问题，编译下载可能是一件挺费时的事情，所以，一次下载要能够有计划
的同时调试多个问题。
另外，断点调试笔者认为主要针对问题已经有疑点了，对根本还未发现问题或者问题不清晰，建议用其它的调试方法，以提高效率。还有，在有些情况下，可能不允许打断点调试（可能会破坏时序）
2)trace工具
很多平台通过PC的串口实现了调试信息的输出，这种调试工具需要在代码中调用相应的接口打印调试信息，所有调试效率的高低就取决于你对程序流程的把握上，如果你在流程关键处能够合理的输出调试信息，会大大提高你的调试效率，还有，trace消息一般是可以方便得进行保存，比较利于让异地的合作方分析问题。当然，trace工具也有他的缺点，首先他不如单步调试直观，当问题范围已经比较小的时候，他的效率可能不及单步，其次则是个比较严重的问题，那就是当你trace消息比较多的时候，容易丢消息，所以trace工具的可靠性就大打折扣。
3)输出内存
有的平台支持断点调试，又可以将某块内存的内容输出到PC上，这时就可以利用该工具进行调试在断点不太允许，trace又变得很不可靠的条件下，可以利用一块静态缓冲区来作为trace缓冲，将非常重要的trace消息写到该缓冲中，然后在需要看trace的时候打断点，将内存内容也就是trace信息输出到PC上来进行分析
4)输出文件
有的平台支持将flash上的文件下载到PC上，此时可以利用这个特性来输出调试信息在断点不允许，trace不可靠，静态缓冲开不出的请况下，可以将trace消息写到文件中，然后通过相应的下载工具，将trace消息写入的文件下载到pc上，进行分析
5)调试策略
a.重现bug
b.分析现象，找出bug出现的条件（每次必现或者是一定条件下出现），尽可能地推测
及估计错误产生的原因，可能的位置
c.仔细地检查相关的代码，很多错误都可以从代码上直接看出来
d.如果无法定位到问题，则采用一步步缩小范围的策略，将相关的代码或者程序一步步分离开来，简化程序和程序运行的环境及条件，一步步逼近疑点
e.结合各种调试手段分析问题
6）一些常见bug的分析（待补充）
a.程序跑飞的可能情况：堆栈溢出；非法地址操作；某些变量被不正常改写；有些平台的全局变量在声明时赋值就是全局变量，对这些变量重新赋值也会跑飞
案例6：
移植程序，移植接口疏忽大意，导致相互嵌套，如A中调用了B，B中调用了C，C在某些情况下又调用到了A，且没有终止嵌套的条件，结果导致堆栈溢出，程序跑飞

案例7：
测试代码
for(i=0;i<buflen;i++)
{
sprintf(TestBuf,buf,"%d");
}
其中由于buf里面的数据是以16进制存的，而sprintf将其以10进制存成字符串，因此可能buf一个字节写到TestBuf中就变成了两个字节，导致了缓冲溢出

b.内存泄漏的调试
a.如果有监测工具，则利用调试工具，在加上必要的测试代码
b.如果没有监测工具，自己书写一套内存分配监测的接口，调试的时候打开接口，运行是观察内存分配的情况，分析是否有泄漏出现

3.其它
1)双方或者多方合作的项目，由于你根本无法预测对方的软件、代码可靠性，集成以后的环境又比较复杂，所以必须做好自己的单元测试和模块测试，有可能的话，你可以以一个最简单的方式模拟他方的行为或者程序，脱离他方的代码进行单独的调试，这在集成以后出现问题查起来的时候会对你相当有帮助