嵌入式linux应用程序调试方法.docx
《嵌入式linux应用程序调试方法.docx》由会员分享,可在线阅读,更多相关《嵌入式linux应用程序调试方法.docx(40页珍藏版)》请在冰点文库上搜索。
嵌入式linux应用程序调试方法
—前言 2
二嵌入式linux的NFS开发环境的建立 7
三GDB调试应用程序 14
四内存工具 17
4.1MEMWATCH 17
4.2YAMD 22
4.3ElectricFence 24
五C/C++代码覆盖、性能profiling工具 24
5.1用gcov来测试代码覆盖率 25
5.2使用gprof来优化你的C/C++程序 35
文件名
嵌入式linux应用程序调试方法
适
用
创
建
作者
飞越丛林
时间
2007-08-08
版本号
V0.1
说明:
参考网络上的资料对nfs;gdb+gdbserver;gcov,gprof进行了一些描述;有不少资料是直接拷贝过来的,只相当于尝试汇总一下吧J;实际上还处于毛胚阶段。
修
改
作者
时间
版本号
感觉偶们项目组的调试手段很匮乏,刀耕火种也许有点过分,但是也差不多;当然这和偶这个小组长的能力有关,自己先汗一个。
不过没有办法,整天要浸泡在对流程从头到尾的探索,修改,再探索,再
修改;经验一点一点艰难的积累…..顾此失彼,没有更多的时间来思考更多的手段问题,算是一个接口吧。
痛定思痛,还是想办法提高一点生产力。
在公司内没有找到相关的资料,于是这段时间就从网络这个巨人那里讨教窃取了一些资料,结合自己的项目stepbystep,“生产工具能够促进生产力的发展”,工具还是给调试带来了很多便利;因为记性不好,随手将一些资料连同自己的使用情况记录了下来,共享出来希望对大家能够有所帮助。
由于缺乏操作系统移植经验,很多东西没有系统知识的支持,在目标板上只能浅尝辄止,没有更深入的探讨,东西比较浅显,光脚不怕穿鞋的,抛砖引玉,希望更多的人能够将自己的使用经验分享出来,将linux的共享精神发扬光大J。
当然也方便我们根据你的经验“拿来主义”。
—前言
在嵌入式软件开发过程中,一般来说,花在测试和花在编码的时间比为3:
1(实际上可能更多)。
这个比例随着你的编程和测试水平的提高而不断下降,但不论怎样,软件测试对一般人来讲很重要。
很多年前,一位开发人员为了对嵌入式有更深层次的理解,向Oracle询问了这样的一个问题:
我怎么才能知道并懂得我的系统到底在干些什么呢?
Oracle面对这个问题有些吃惊,因为在当时没有人这么问过,而同时代的嵌入式开发人员问的最多的大都围绕“我怎么才能使程序跑的更快”、“什么编译器最好”等肤浅的问题。
所以,面对这个不同寻常却异乎成熟的问题,Oracle感到欣喜并认真回复了他:
你的问题很有深度
很成熟,因为只有不断地去深入理解才有可能不断地提高水平。
并且Oracle为了鼓励这位执着的程序员,把10条关于嵌入式软件开发测试的秘诀告诉了他:
1.懂得使用工具
2.尽早发现内存问题
3.深入理解代码优化
4.不要让自己大海捞针
5.重现并隔离问题
6.以退为进
7.确定测试的完整性
8.提高代码质量意味着节省时间
9.发现它,分析它,解决它
10.利用初学者的思维
这十条秘诀在业界广为流传,使很多人受益。
本文围绕这十条秘诀展开论述。
1.懂得使用工具
通常嵌入式系统对可靠性的要求比较高。
嵌入式系统安全性的失效可能会导致灾难性的后果,即使是非安全性系统,由于大批量生产也会导致严重的经济损失。
这就要求对嵌入式系统,包括嵌入式软件进行严格的测试、确认和验证。
随着越来越多的领域使用软件和微处理器控制各种嵌入式设备,对门益复杂的嵌入式软件进行快速有效的测试愈加显得重要。
就象修车需要工具一样,好的程序员应该能够熟练运用各种软件工具。
不同的工具,有不同的使用范围,有不同的功能。
使用这些工具,你可以看到你的系统在干些什么,它又占用什么资源,它到底和哪些外界的东西打交道。
让你郁闷好几天的问题可能通过某个工具就能轻松搞定,可惜你就是不知道。
那么为什么那么多的人总是在折腾个半死之后才想到要用测试工具呢?
原因很多,主要有两个。
一个是害怕,另一个是惰性。
害怕是因为加入测试用具或测试模块到代码需要技巧同时有可能引入新的错误,所以他们总喜欢寄希望于通过不断地修改重编译代码来消除bug,结果却无济于事。
懒惰是因为他们习惯了使用printf之类的简单测试手段。
下面来介绍一些嵌入式常用的测试工具。
.源码级调试器[Source-levelDebugger]
这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能,是嵌入式调试最根本有效的调试方法。
比如VxWorksTornadoII提供的gdb就属于这一种。
.简单实用的打印显示工具[printf]
printf或其它类似的打印显示工具估计是最灵活最简单的调试工具。
打印代码执行过程中的各种变量可以让你知道代码执行的情况。
但是,printf对正常的代码执行干扰比较大(一般printf占用CPU比较长的时间),需要慎重使用,最好设置打印开关来控制打印。
.ICE或JTAG调试器[In-circuitEmulator]
ICE是用来仿真CPU核心的设备,它可以在不干扰运算器的正常运行情况下,实时的检测CPU的内部工作情况。
像桌面调试软件所提供的:
复杂的条件断点、先进的实时跟踪、性能分析和端口分析这些功能,它也都能提供。
ICE一般都有一个比较特殊的CPU,称为外合(bond-out)CPU。
这是一种被打开了封装的CPU,并且通过特殊的连接,可以访问到CPU的内部信号,而这些信号,在CPU被封装时,是没法“看到”的。
当和工作站上强大的调试软件联合使用时,ICE就能提供你所能找到的最全面的调试功能。
但ICE同样有一些缺点:
昂贵;不能全速工作;同样,并不是所有的CPU都可以作为外合CPU的,从另一个角度说,这些外合CPU也不大可能及时的被新出的CPU所更换。
JTAG(JointTestActionGroup)虽然它最初开发出来是为了监测IC和电路连接,但是这种串行接口扩展了用途,包括对调试的支持。
AD公司
为Blackfin设计的VisualDsp++就支持高速的JTAG调试。
.ROM监视器[ROMMonitor]
ROM监控器是一小程序,驻留在嵌入系统ROM中,通过串行的或网络的连接和运行在工作站上的调试软件通信。
这是一种便宜的方式,当然也是最低端的技术。
它除了要求一个通信端口和少量的内存空间外,不需要其它任何专门的硬件。
并提供了如下功能:
下载代码、运行控制、断点、单步步进、以及观察、修改寄存器和内存。
因为ROM监控器是操作软件的一部分,只有当你的应用程序运行时,它才会工作。
如果你想检查CPU和应用程序的状态,你就必须停下应用程序,再次进入ROM监控器。
.Data监视器[DataMonitor]
这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容,还可以收集并以图形形式显示各个变量的变化过程。
.OS监视器[OperatingSystemMonitor]
操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。
一方面,这些监视器能够为你呈现事件之间的关系和时间联系;另一方面,还可以提供对信号量优先级反转、死锁和中断延时等问题的诊断。
.性能分析工具[Profiler]
可以用来测试CPU到底耗在那里。
profiler工具可以让你知道系统的瓶颈在那里、CPU的使用率以及需要优化的地方。
.内存测试工具[MemoryTeseter]
可以找到内存使用的问题所在,比如内存泄露、内存碎片、内存崩溃等问题。
如果发现系统出现一些不可预知的或间歇性的问题,就应该使用内存测试工具测测看。
.运行跟踪器[ExecutionTracer]
可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。
这种工具主要用于测试代码逻辑,可以在大量的事件中发现异常的那些。
.覆盖工具[CoverageTester]
主要显示CPU具体执行了那些代码,并让你知道那些代码分支没有被执行到。
这样有助于提高代码质量并消除无用代码。
.GUI测试工具[GUITester]
很多嵌入式应用带有某种形式的图形用户界面进行交互,有些系统性能测试足根掘用户输入响应时间进行的。
GUI测试工具可以作为脚本工具有开发环境中运行测试用例,其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程(Rational公司的robot和Mercury的Loadrunner工具是杰出的代表)。
很多嵌入式设备没有GUI,但常常可以对嵌入式设备进行插装来运行GUI测试脚本,虽然这种方式可能要求对被测代码进行更改,但是节省了功能测试和回归测试的时间。
.自制工具[Home-madetester]
在嵌入式应用中,有时候为了特定的目的,需要自行编写一些工具来达到某种测试目的。
本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上帮了大忙,帮公司找到了几个隐藏很深的bug。
2.尽早发现内存问题
内存问题危害很大,不容易排查,主要有三种类型:
内存泄露、内存碎片和内存崩溃。
对于内存问题态度必须要明确,那就是早发现早“治疗”。
在软件设计中,内存泄露的“名气”最大,主要由于不断分配的内存无法及时地被释放,久而久之,系统的内存耗尽。
即使细心的编程老手有时后也会遭遇内存泄露问题。
有测试过内存泄露的朋友估计都有深刻地体验,那就是内存泄露问题一般隐藏很深,很难通过代码阅读来发现。
有些内存泄露甚至可能出现在库当中。
有可能这本身是库中的bug,也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。
在很多时候,大多数的内存泄露问题无法探测,但可能表现为随机的故障。
程序员们往往会把这种
现象怪罪于硬件问题。
如果用户对系统稳定性不是很高,那么重启系统问题也不大;但,如果用户对系统稳定很高,那么这种故障就有可能使用户对产品失去信心,同时也意味着你的项目是个失败的项目。
由于内存泄露危害巨大,现在已经有许多工具来解决这个问题。
这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。
每个工具都有利有弊,不过总的来说,用要比不用好。
总之,负责的开发人员应该去测试内存泄露的问题,做到防患于未然。
内存碎片比内存泄露隐藏还要深。
随着内存的不断分配并释放,大块内存不断分解为小块内存,从而形成碎片,久而久之,当需要申请大块内存是,有可能就会失败。
如果系统内存够大,那么坚持的时间会长一些,但最终还是逃不出分配失败的厄运。
在使用动态分配的系统中,内存碎片经常发生。
目前,解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首,然后改进相应的部分。
由于动态内存管理的种种问题,在嵌入式应用中,很多公司干脆就禁用malloc/free的以绝后患。
内存崩溃是内存使用最严重的结果,主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。
这种内存崩溃造成系统故障是随机的,而且很难查找,目前提供用于排查的工具也很少。
总之,如果要使用内存管理单元的话,必须要小心,并严格遵守它们的使用规则,比如谁分配谁释
放。
3.深入理解代码优化
讲到系统稳定性,人们更多地会想到实时性和速度,因为代码效率对嵌入式系统来说太重要了。
知道怎么优化代码是每个嵌入式软件开发人员必须具备的技能。
就象女孩子减肥一样,起码知道她哪个地方最需要减,才能去购买减肥药或器材来减掉它。
可见,代码优化的前提是找到真正需要优化的地方,然后对症下药,优化相应部分的代码。
前面提到的profile(性能分析工具,一些功能齐全IDE都提供这种内置的工具)能够记录各种情况比如各个任务的CPU占用率、各个任务的优先级是否分配妥当、某个数据被拷贝了多少次、访问磁盘多少次、是否调用了网络收发的程序、测试代码是否已经关闭等等。
但是,profile工具在分析实时系统性能方面还是有不够的地方。
一方面,人们使用profile工具往往是在系统出现问题即CPU耗尽之后,而profile工具本身对CPU占用较大,所以profile对这种情况很可能不起作用。
根据Heisenberg效应,任何测试手段或多或少都会改变系统运行,这个对profiler同样适用!
总之,提高运行效率的前提是你必须要知道CPU到底干了些什么干的怎么样。
4.不要让自己大海捞针
大海捞针只是对调试的一种生动比喻。
经常听到组里有人对自己正在调试的代码说shit!
可以理解,因为代码不是他写的,他有足够的理由去shitbug百出的代码,只要他自己不要写出这种代码,否则有一天同组的其它人可能同样会shit他写的代码。
为何会有大海捞针呢?
肯定是有人把针掉到海里咯;那针为何会掉在海里呢?
肯定是有人不小心或草率呗。
所以当你在抱怨针那么难找的时候,你是否想过是你自己草率地丢掉的。
同样,当你调试个半死的时候,你是否想过你要好好反省一下当初为了寻求捷径可能没有严格地遵守好的编码设计规范、没有检测一些假设条件或算法的正确性、没有将一些可能存在问题的代码打上记号呢?
关于如何写高质量请参考林锐的《高质量c++/c编程指南》或《关于C的0x8本“经书”》。
如果你确实已经把针掉在海里是,为了防止在找到之前刺到自己,你必须要做一些防范工作,比如戴上安全手套。
同样,为了尽能地暴露和捕捉问题根源,我们可以设计比较全面的错误跟踪代码。
怎么来做呢?
尽可能对每个函数调用失败作出处理,尽可能检测每个参数输入输出的有效性包括指针以及检测是否过多或过少地调用某个过程。
错误跟踪能够让你知道你大概把针掉在哪个位置。
5.重现并隔离问题
如果你不是把针掉在大海了,而是掉在草堆里,那要好办写。
因为至少我们可以把草堆分成很多块,一块一块的找。
对于模块独立的大型项目,使用隔离方法往往是对付那些隐藏极深bug的最后方法。
如果问题的出现是间歇性的,我们有必要设法去重现它并记录使其重现的整个过程以备在下一次可以利用这些条件去重现问题。
如果你确信可以使用记录的那些条件去重现问题,那么我们就可以着手去隔离问题。
怎么隔离呢?
我们可以用#ifdef把一些可能和问题无关的代码关闭,把系统最小化到仍能够重现问题的地步。
如果还是无法定位问题所在,那么有必要打开“工具箱”了。
可以试着用ICE或数据监视器去查看某个可疑变量的变化;可以使用跟踪工具获得函数调用的情况包括参数的传递;检查内存是否崩溃以及堆栈溢出的问题。
6.以退为进
猎人为了不使自己在森林里迷路,他常常会在树木上流下一些标记,以备自己将来有一天迷路时可以根据这些标记找到出路。
对过去代码的修改进行跟踪记录对将来出现问题之后的调试很有帮助。
假如有一天,你最近一次修改的程序跑了很久之后忽然死掉了,那么你这时的第一反映就是我到底改动了些什么呢,因为上次修改之前是好的。
那么如何检测这次相对于上次的修改呢?
没错,代码控制系统SCS或称版本控制系统VCS(ConcurrentVersionControl,CVS是VCS的演化版本)。
将上个版本checkin下来后和当前测试版本比较。
比较的工具可以是SCS/VCS/CVS自带的diff工具或其它功能更强的比较工具,比如BeyondCompare和ExamDiff。
通过比较,记录所有改动的代码,分析所有可能导致问题的可疑代码。
7.确定测试的完整性
你怎么知道你的测试有多全面呢?
覆盖测试(coveragetesting)可以回答这个问题。
覆盖测试工具可以告诉你CPU到底执行了那些代码。
好的覆盖工具通常可以告诉你大概20%到40%代码没有问题,而其余的可能存在bug。
覆盖工具有不同的测试级别,用户可以根据自己的需要选择某个级别。
即使你很确信你的单元测试已经很全面并且没有deadcode,覆盖工具还是可以为你指出一些潜在的问题,看下面的代码:
if(i>=0&&(almostAlwaysZero==0||(last=i)))
如果almostAlwaysZero为非0,那么last=i赋值语句就被跳过,这可能不是你所期望的。
这种问题通过覆盖工具的条件测试功能可以轻松的被发现。
总之,覆盖测试对于提高代码质量很有帮助。
8.提高代码质量意味着节省时间
有研究表明软件开发的时间超过80%被用在下面几个方面:
.调试自己的代码(单元测试)
.调试自己和其他相关的代码(模块间测试)
.调试整个系统(系统测试)
更糟糕的是你可能需要花费10-200倍的时间来找一个bug,而这个bug在开始的时候可能很容易就能找到。
一个小bug可能让你付出巨大的代价,即使这个bug对整个系统的性能没有太大的影响,但很可能会影响让那些你可以看得到的部分。
所以我们必须要养成良好的编码和测试手段以求更高的代码质量,以便缩短调试的代码。
9.发现它,分析它,解决它
这世界没有万能的膏药。
profile再强大也有力不从心的时候;内存监视器再好,也有无法发现的时候;覆盖工具再好用,也有不能覆盖的地方。
一些隐藏很深的问题即使用尽所有工具也有可能无法查到其根源,这时我们能做的就是通过这些问题所表现出来的外在现象或一些数据输出来发现其中的规律或
异常。
一旦发现任何异常,一定要深入地理解并回溯其根源,直到解决为止。
10.利用初学者的思维
有人这样说过:
“有些事情在初学者的脑子里可能有各种各样的情况,可在专家的头脑里可能就很单一”。
有时候,有些简单的问题会被想的很复杂,有些简单的系统别设计的很复杂,就是由于你的“专家思维”。
当你被问题难住时,关掉电脑,出去走走,把你的问题和你的朋友甚至你的小狗说说,或许他们可以给你意想不到的启发。
总结:
嵌入式调试也是一门艺术。
就想其它的艺术一样,如果你想取得成功,你必须具备智慧、经验并懂得使用工具。
只要我们能够很好地领悟Oracle这十条秘诀,我相信我们在嵌入式测试方面就能够取得成功。
武功秘籍排行榜:
1.TheCprogramminglanguage《C程序设计语言》
2.PointersonC《C和指针》
3.Ctrapsandpitfalls《C陷阱与缺陷》
4.ExpertCLanuage《专家C编程》
5.WritingCleanCode
-----MicrosoftTechiniquesforDevelopingBug-freeCPrograms
《编程精粹--Microsoft编写优质无错C程序秘诀》
6.ProgrammingEmbeddedSystemsinCandC++《嵌入式系统编程》7.《C语言嵌入式系统编程修炼》
8.《高质量C++/C编程指南》林锐
9《C语言解惑》
二嵌入式linux的NFS开发环境的建立
在两台linuxpc之间共享资源通常我们采用NFS技术;而在linux和windows之间共享资源,通常我们采用samba技术[]。
NFS可以让你的PC通过网络将远端的NFS 服务器共享出来的文件mount到自己的系统中,在客户端看来使用NFS的远端文件就象是在使用本地文件一样。
使用NFS可以使应用程序的开发变得十分方便, 客户端不需要大容量的存储器,更不需要进行映像文件的烧录和下载,只要mount到服务器端的特定目录下,然后运行该目录下的程序即可观察到结果。
建立NFS开发环境的工作分为两个方面,配置NFS服务器和配置客户端。
在开始前需要特别说明的一点:
这里的描述是针对自己使用情况的简单记录,可能你在使用过程中会存在一些问题,关于更多关于nfs和使用过程中的问题,建议参考这个网站上的资料和FAQ。
在应用程序开发环节,NFS方式比ftp方式的执行效率要高,因为它不需要将linuxserver端的程序下载到嵌入式目标系统就可以调试。
下面先将NFS建立的详细过程写一下,然后举一个简单的应用程序开
发实例来比较ftp方式和nfs方式的不同。
1建立NFS开发环境
嵌入式linux的NFS开发环境包含着两个方面:
一是linux server端的NFS Server支持;二是
targetboard的NFSClient支持。
1.1linuxserver端
1.1.1以root的身份登录,编译共享目录的配置文件exports,指定共享目录及其权限。
#vi/etc/exports
在该文件中添加:
/home/lqm(共享目录)192.168.1.*(rw,sync,no_root_squash)
添加的内容表示允许IP范围在192.168.1.*的计算机以读写的权限来访问共享目录/home/lqm。
【注:
】
参数说明如下:
rw---读/写权限。
如果设定只读权限,则设为ro。
但是一般情况下,为了方便交互,要设置为rw。
sync--数据同步写入内存和硬盘。
no_root_squash--此参数用来要求服务器允许远程系统以它自己的root特权存取该目录。
就是说,
如果用户是root,那么他就对这个共享目录有root的权限。
很明显,该参数授予了targetboard很大的权利。
安全性是首先要考虑的,可以采取一定的保护机制,在下面会讲一下保护机制。
如果使用默认的root_squash,targetboard自己的根文件系统可能有很多无法写入,所以运行会受到极大的限制。
在安全性有所保障的前提下,推荐使用no_root_squash参数。
ro:
只读的权限,系统默认选项;如果不明确指定rw,系统默然采用这种方式;
root_squash:
在登入NFS主机使用分享之目录的使用者如果是root时,那么这个使用者的权限将被压缩成为匿名使用者,通常他的UID与GID都会变成nobody那个身份;如果不明确指定no_root_squas,系统默然采用这种方式;
all_squash:
不论登入NFS的使用者身份为何,他的身份都会被压缩成为匿名使用者,通常也就是
nobody啦!
anonuid:
前面关于*_squash提到的匿名使用者的UID设定值,通常为nobody,但是你可以自行设定这个UID的值!
当然,这个UID必需要存在于你的/etc/passwd当中!
anongid:
同anonuid,但是变成groupID就是了;
async:
资料会先暂存于内存当中,而非直接写入硬盘;
1.1.2起用保护机制
可以通过设定/etc/hosts.deny和/etc/hosts.allow文件来限制网络服务的存取权限。
***/etc/hosts.deny***portmap:
ALLlockd:
ALLmountd:
ALLrquotad:
ALLstatd:
ALL
***/etc/h