linux 下 C 编程和make的方法 (五:补充 怎么抓BUG)

中山野鬼 发布于 2012/03/30 22:51
阅读 448
收藏 7
    抓BUG,几乎是程序员必须面对的事情。我没见过一次写通过,不需要改动的,这我承认,我野鬼见的人少,但我也必须说事实,就我本人还没有一次写就通过的模块,且不说系统。已经有条件反射了,如果代码写写,没错,又写写,还是没错。立刻停下来,琢磨琢磨哪出问题了。有些人说“你已经变态到不是人的境界了”。我只能说,每次停下来,发现,恩确实有问题。
    由此引发个支持IDE的理由。很多人说新手容易出BUG,DEBUG,IDE的工具很方便。难道你要教新手GDB吗?那不适合新手学。我只能说,GDB我也不会用啊。估计目前倒下、抽筋,呕吐的一片,还好我没收学费。
    很多年一直用VC,因为VC的debug我很熟练。后来发现不行了,怎么不行了,上板子就不行了。有人说,JTAG抓。抓回来看,这和VC也没关系啊。唯一DEBUG看寄存器的是自己写汇编,那没办法。但这种情况,不在我讨论的范畴,我没说linux 下汇编的设计。这本身就是错误的命题,应该是什么硬件平台上汇编的设计。但即便是DEBUG汇编我也是在SIMU,模拟器上使用,上板子没办法玩。为什么,不是JTAG坏了,而是大多数有如下两种情况:
    1、多进程或多核之间的连动工作。我设置端点,只要一停,这个核处于静态,那边过一秒没有底层响应就认为核死了,没办法动态跟踪。
    2、函数套函数,而且运行了不知道多少次以后才出现。运行个3分钟可能你还能忍受,如果一个系统运行1个小时,在足够多的任务下才存在,要么内存严重不足,要么指针跑飞,同志们倒是送我个合理化建议,如何通过设置断点,看寄存器来DEBUG。
    没办法,活还要干,如同饭还要吃一样,这样不行,只有换方法。什么方法?替换,检测,正向分析法。
    1、替换。模块的替换,替换模块一个好一个坏,那就是两个模块之间出现差异。这样缩小范围。
    2、LOG打印,检测不同情况下,存储单元的数值是否正常。怎么检测,批次输出,同时有正确版本也输出,对比找到出错位置。就可以知道那次输出的存储数据出错。
    3、错了就分析原因,谁引发的,然后锁定具体代码片,接着推倒重新设计。而不是反过来理解跟踪判断。
    哇塞,肯定有人说我第3条弱智。我要补充,既然是C代码,就要模块化,函数的目标要明确。如果你一个函数1000行,错了重新设计几乎还是错,那么就是你组织代码,规划模块的问题了。如果一个函数调用,内部需要100个cycle,函数调用函数的费用平均10个cycle。就是使用子函数,还是有优势的。即便这个函数占到整体计算量的20%(这已经很大了),多10%,也是整体计算量多2%。你有力气到处通过省去函数调用费用来提高速度,还不如重新规划下系统结构,优化下CACHE的数据摆放和内容,看是否有改良的空间。
    上面的1,2,3还有个前提,就是原理性验证版本的正确性。这又回到了,怎么规划函数,的问题上了。因此,抓BUG,从你写代码的第一个单词开始,就已经存在了。不要认为,等你所有代码都写完,再一一抓。程序设计,是迭代的 。模块与模块的迭代,原理与优化的迭代。不要希望自己的代码一次就达到高质量。什么是高质量,就是为你下一次迭代提供良好抓BUG的基础就叫高质量。一把头设计写出来,就拿出用的,那是JAVA们干的应用软件的事情。和你做C没关系。你要做C就安心打铁把,你见过哪个铁匠就敲一下的?你如果说,“我要体面的工作,体面的设计成果”。。。那我没话说,谁都想体面,就是因为谁都想体面,所以一群体面的人,都求着那几个不体面的底层师傅,你要看上去体面,还是实际的体面呢?
    因此,新手不要认为盖高楼就没有脚手架你每天只要和楼板混凝土打交道,那是体面的人做内装潢时,交付给业主阶段才发生的。检测代码是一定要的。只不过是否要在编译中存在,可以通过预编译处理掉。因此余下的C程序设计,我们把GDB丢弃掉。同时对新手说,IDE,你现在该没有任何利用使用它了。
加载中
返回顶部
顶部