如何在嵌入式Linux产品中做立体、覆盖产品生命期的调试：
在嵌入式Linux产品中的调试不像window环境下有很好的IDE支持，对于如何做好综合运用下面的手段，做个立体、覆盖产品生命期的调试；
1 print
2 syslog
3 gdb/gdbserver/core
4 error_code
5 change log
6 memory leak
7 lock file
8 thread lock
9 try catch
10 performance test
11 blue screen/screenshot
一般情况下，我们会在程序中安插不少print语句，但是一味的放置过多的打印语句，有很多的弊病，这也是大部分开发人员面临的问题：
问题1: 开发人员要在debug状态下才能看到打印的信息；
问题2: 产品正常运行时，看不到这些信息，而且过多的打印会影响产品的速度；
所以，何时，如何放置打印语句也是要考虑的；
问题 3: 如果打印结合log文件就更好了，对于影响程序比较深的部分除了打印，要以Log的形式记录下来，事后便于开发人员分析原因；
问题4: Linux 下面gdb调试是个利器，不过gdb调试exe文件没有任何问题，但是对于调试so文件就不那么友好了，为了调试so,还要做些反汇编的动作；
问题 5: 而且嵌入式产品，尤其是手机产品，跑得程序比较多，在不同的进程中，往往是父进程fork出子进程，gdb如何远程调试target侧fork出的进程中运行的so库呢？这是一个比较复杂的问题；
问题 6：在程序崩掉时，我们往往靠猜想，想问题到底出现在哪呢？这时就用到了core文件了；让我们的程序在崩掉时做个内存映像，然后结合gdb/gdbserver做事后的分析；
问题 7：除了事后分析问题的方法，比如看Log；调试core;还有其他的手段吗？有，就是抓屏幕，当出现问题时/或者出现了严重的错误，可以把当时的屏幕情况保存为一幅图片，存下来，然后我们的事后可以很方便的看到当时的情况；另外在开发阶段还可以把严重的问题直接以蓝屏或者红屏的形式显示在屏幕上；
问题8：如何合理的利用error_code也是一个非常好的问题；如果我们调用的库提供获取error_code对应的error_string的话，就一定要用，不用客气，这在发现问题方面很有用；另外，如果自己开发比较底层的构件，比如说Middleware一层的代码，就一定要提供完整的error_code, 并封装出自己的获取error_string的函数给用户使用，没有error_string的代码是非常不完善的；
问题 9：对于平时的开发，release,一定要维护一个change log, 不同的人对于在哪写change log都有不同的理解，但最好有，对于调试、发现问题很重要；
问题 10: 对于try/catch的使用不要流于形式，我发现有的开发人员为了try/catch而try/catch,没有起到实效；另外try/catch要结合log的使用更高效；
问题 11: 对于程序performance的检查要做到常态，这好像和debug的关系不大，的确不大；呵呵，不过把performance test的代码结合log的使用可以很方便、随时监控程序运行的效率；
如果在嵌入式Linux产品中综合运用上面的方式，将会很大的提高调试的效率；为此我将针对上面的问题发布系列的博文，谈谈我对这些问题的看法，也是和大家一个交流吧；
后面将会推出大概11篇左右的连续、相关联的探讨......
发表于 @ 2007年12月13日 14:32:00|评论(loading...)|编辑