2009年3月29日星期日
10个方法提高你的编程生产力
信息爆炸的年代新闻数量多不胜数,不要阅读过多的新闻,我一般一天阅读两次新闻,早晨和下午各打开一次google
reader,更多的新闻阅读将会严重降低工作效率。
2。给自己精心准备一个工作开始的起点
写程序一旦进入状态,毫无疑问效率是非常高的,脑子里面每个细胞似乎都在奋斗。但是如何快速进入完美的工作状态?我的经验是,每当我离开工作的时候,比如
中午午餐时间前或者一天工作结束时候,我会故意遗留一个未完成小任务在我的程序里面。当我回来工作的时候,我能够迅速知道从哪里开始,专心致志解决完这个
小任务,我的大脑差不多已经完成热身了,马上能够进入真正的工作。
3。用笔画出来,做好预先研究工作
怎么说呢,就是脑子的想法尽可能的用笔画出来,形象化的图形能够很好的帮助你思考总结。
对于复杂的工作,预先做好研究工作,比如一个难度很大的算法程序,我会先搞懂最难的技术问题才开始写代码。
4。建立一个完美的工作环境
大多数我们都是在公司工作,工作环境不能由我们决定,但是至少我们可以在自己家里弄一个完美的工作环境。我心目中好的工作环境包括:
a)一个大电脑显示器,一张大桌子
b)一个舒服的电脑椅
c)有益工作的背景音乐,这个因人而异
d)一套好的音响
e)阳光充足的窗口
f)大的开放的空间
g)安静,很少有人在旁边走动
h)和外界通风良好
i)房间是现代装饰风格
5。工作时间关掉IM工具
不管什么理由,都要坚决关掉所有的IM工具
6。工作时间只回复和处理紧急邮件
不要让邮件打断你的工作节奏,工作时间只回复和处理紧急邮件
7。减少开会,一周一次会议或者更少
保持沟通效率高效,但不是更多的会议。减少开会,一周一次会议或者更少。
8。每两周参加一次社交活动
程序员的生活是比较单调的,我所说的社交活动并不是和同事,工作伙伴之间的交流,也不是你依然坐在电脑桌前玩游戏。而是走出你的办公室,和你工作以外的朋友在一起交流,量身打造你自己的情感需求。
9。放松的夜晚
没有比7×24小时连续工作更糟了。长时间处于兴奋和焦虑状态会极大影响你长期的工作效率。每天休息一段时间,散步,阅读,享受生活,你会发现你的创造力提高了。
10。每周3次,每次20分钟的体育运动
体育运动并不是浪费时间,定期的体育活动会让你精力更加充沛,头脑反映更加灵活。保持至少每周3次,每次20分钟的体育运动。
GCC使用入门
通 常所说的GCC是GUN Compiler
Collection的简称,除了编译程序之外,它还含其他相关工具,所以它能把易于人类使用的高级语言编写的源代码构建成计算机能够直接执行的二进制代
码。GCC是Linux平台下最常用的编译程序,它是Linux平台编译器的事实标准。同时,在Linux平台下的嵌入式开发领域,GCC也是用得最普遍
的一种编译器。GCC之所以被广泛采用,是因为它能支持各种不同的目标体系结构。例如,它既支持基于宿主的开发(简单讲就是要为某平台编译程序,就在该平
台上编译),也支持交叉编译(即在A平台上编译的程序是供平台B使用的)。目前,GCC支持的体系结构有四十余种,常见的有X86系列、Arm、
PowerPC等。同时,GCC还能运行在不同的操作系统上,如Linux、Solaris、Windows等。
除了上面讲的之外,GCC除了支持C语言外,还支持多种其他语言,例如C++、Ada、Java、Objective-C、FORTRAN、Pascal等。
本系列文章中,我们不仅介绍GCC的基本功能,还涉及到一些诸如优化之类的高级功能。另外,我们还考察GCC的一些映像操作工具,如size和objcopy等,这将在后续的文章中加以介绍。
二、程序的编译过程
对于GUN编译器来说,程序的编译要经历预处理、编译、汇编、连接四个阶段。从功能上分,预处理、编译、汇编是三个不同的阶段,但GCC的实际操作上,它可以把这三个步骤合并为一个步骤来执行。下面我们以C语言为例来谈一下不同阶段的输入和输出情况。
在
预处理阶段,输入的是C语言的源文件,通常为*.c。它们通常带有.h之类头文件的包含文件。这个阶段主要处理源文件中的#ifdef、
#include和#define命令。该阶段会生成一个中间文件*.i,但实际工作中通常不用专门生成这种文件,因为基本上用不到;若非要生成这种文件
不可,可以利用下面的示例命令:
gcc -E test.c -o test.i
在编译阶段,输入的是中间文件*.i,编译后生成汇编语言文件*.s
。这个阶段对应的GCC命令如下所示:
GCC -S test.i -o test.s
在汇编阶段,将输入的汇编文件*.s转换成机器语言*.o。这个阶段对应的GCC命令如下所示:
GCC -c test.s -o test.o
最后,在连接阶段将输入的机器代码文件*.s(与其它的机器代码文件和库文件)汇集成一个可执行的二进制代码文件。这一步骤,可以利用下面的示例命令完成:
GCC test.o -o test
上面介绍了GCC编译过程的四个阶段以及相应的命令。下面我们进一步介绍常用的GCC的模式。
三、GCC常用模式
这里介绍GCC追常用的两种模式:编译模式和编译连接模式。下面以一个例子来说明各种模式的使用方法。为简单起见,假设我们全部的源代码都在一个文件test.c中,要想把这个源文件直接编译成可执行程序,可以使用以下命令:
$ GCC -o test
这里test.c是源文件,生成的可执行代码存放在一个名为test
的文件中(该文件是机器代码并且可执行)。-o
是生成可执行文件的输出选项。如果我们只想让源文件生成目标文件(给文件虽然也是机器代码但不可执行),可以使用标记-c
,详细命令如下所示:
$ GCC -c test.c
默认情况下,生成的目标文件被命名为test.o,但我们也可以为输出文件指定名称,如下所示:
$ GCC -c test.c -o
上面这条命令将编译后的目标文件命名为mytest.o,而不是默认的test.o。
迄今为止,我们谈论的程序仅涉及到一个源文件;现实中,一个程序的源代码通常包含在多个源文件之中,这该怎么办?没关系,即使这样,用GCC处理起来也并不复杂,见下例:
$ GCC -o test first.c second.c third.c
需
要注意的是,要生成可执行程序时,一个程序无论有有一个源文件还是多个源文件,所有被编译和连接的源文件中必须有且仅有一个main函数,因为main函
数是该程序的入口点(换句话说,当系统调用该程序时,首先将控制权授予程序的main函数)。但如果仅仅是把源文件编译成目标文件的时候,因为不会进行连
接,所以main函数不是必需的。
四、常用选项
许多情况下,头文件和源文件会单独存放在不同的目录中。例如,假设存放源文件的子目录名为./src,而包含文件则放在层次的其他目录下,如./inc。当我们在./src
目录下进行编译工作时,如何告诉GCC到哪里找头文件呢?方法如下所示:
$ gcc test.c –I../inc -o test
上面的命令告诉GCC包含文件存放在./inc
目录下,在当前目录的上一级。如果在编译时需要的包含文件存放在多个目录下,可以使用多个-I
来指定各个目录:
$ gcc test.c –I../inc –I../../inc2 -o test
这里指出了另一个包含子目录inc2,较之前目录它还要在再上两级才能找到。
另外,我们还可以在编译命令行中定义符号常量。为此,我们可以简单的在命令行中使用-D选项即可,如下例所示:
$ gcc -DTEST_CONFIGURATION test.c -o test
上面的命令与在源文件中加入下列命令是等效的:
#define TEST_CONFIGURATION
在编译命令行中定义符号常量的好处是,不必修改源文件就能改变由符号常量控制的行为。
五、警告功能
当
GCC在编译过程中检查出错误的话,它就会中止编译;但检测到警告时却能继续编译生成可执行程序,因为警告只是针对程序结构的诊断信息,它不能说明程序一
定有错误,而是存在风险,或者可能存在错误。虽然GCC提供了非常丰富的警告,但前提是你已经启用了它们,否则它不会报告这些检测到的警告。
在众多的警告选项之中,最常用的就是-Wall选项。该选项能发现程序中一系列的常见错误警告,该选项用法举例如下:
$ gcc -Wall test.c -o test
该选项相当于同时使用了下列所有的选项:
◆unused-function:遇到仅声明过但尚未定义的静态函数时发出警告。
◆unused-label:遇到声明过但不使用的标号的警告。
◆unused-parameter:从未用过的函数参数的警告。
◆unused-variable:在本地声明但从未用过的变量的警告。
◆unused-value:仅计算但从未用过的值得警告。
◆Format:检查对printf和scanf等函数的调用,确认各个参数类型和格式串中的一致。
◆implicit-int:警告没有规定类型的声明。
◆implicit-function-:在函数在未经声明就使用时给予警告。
◆char-subscripts:警告把char类型作为数组下标。这是常见错误,程序员经常忘记在某些机器上char有符号。
◆missing-braces:聚合初始化两边缺少大括号。
◆Parentheses:在某些情况下如果忽略了括号,编译器就发出警告。
◆return-type:如果函数定义了返回类型,而默认类型是int型,编译器就发出警告。同时警告那些不带返回值的
return语句,如果他们所属的函数并非void类型。
◆sequence-point:出现可疑的代码元素时,发出报警。
◆Switch:如果某条switch语句的参数属于枚举类型,但是没有对应的case语句使用枚举元素,编译器就发出警告(在switch语句中使用default分支能够防止这个警告)。超出枚举范围的case语句同样会导致这个警告。
◆strict-aliasing:对变量别名进行最严格的检查。
◆unknown-pragmas:使用了不允许的#pragma。
◆Uninitialized:在初始化之前就使用自动变量。
需要注意的是,各警告选项既然能使之生效,当然也能使之关闭。比如假设我们想要使用-Wall来启用个选项,同时又要关闭unused警告,利益通过下面的命令来达到目的:
$ gcc -Wall -Wno-unused test.c -o test
下面是使用-Wall选项的时候没有生效的一些警告项:
◆cast-align:一旦某个指针类型强制转换时,会导致目标所需的地址对齐边界扩展,编译器就发出警告。例如,某些机器上只能在2或4字节边界上访问整数,如果在这种机型上把char
*强制转换成int *类型, 编译器就发出警告。
◆sign-compare:将有符号类型和无符号类型数据进行比较时发出警告。
◆missing-prototypes
:如果没有预先声明函数原形就定义了全局函数,编译器就发出警告。即使函数定义自身提供了函数原形也会产生这个警告。这样做的目的是检查没有在头文件中声明的全局函数。
◆Packed:当结构体带有packed属性但实际并没有出现紧缩式给出警告。
◆Padded:如果结构体通过充填进行对齐则给出警告。
◆unreachable-code:如果发现从未执行的代码时给出警告。
◆Inline:如果某函数不能内嵌(inline),无论是声明为inline或者是指定了-finline-functions
选项,编译器都将发出警告。
◆disabled-optimization:当需要太长时间或过多资源而导致不能完成某项优化时给出警告。
上面是使用-Wall选项时没有生效,但又比较常用的一些警告选项。本文中要介绍的最后一个常用警告选项是-Werror。使用该选项后,GCC发现可疑之处时不会简单的发出警告就算完事,而是将警告作为一个错误而中断编译过程。该选项在希望得到高质量代码时非常有用。
六、小结
本文介绍了GCC的基本编译过程和编译模式,并详细阐述了GCC的一些常用选项以及警告功能。这些是在利用GCC进行应用编程时最基本也最常用的一些内容,我们会在后续文章中继续介绍GCC的调试和优化技术。
该命令将同时编译三个源文件,即first.c、second.c和
third.c,然后将它们连接成一个可执行程序,名为test。
Linux联盟收集整理 ,转贴请标明原始链接,如有任何疑问欢迎来本站Linux论坛讨论
http://www.xxlinux.com/linux/article/development/soft/20061029/5551.html
单字节大小枚举及按位对齐
#include <stdio.h>
enum he {
AGE = 0x01,
NAME = 0x02
};
enum she {
AGE1 = 0x03,
NAME2 = 0x04
};
struct bear {
char x;
char y;
enum he he;
enum she she;
int z;
};
int main(int argc, char **argv)
{
int size = 0;
struct bear bear;
size = sizeof(struct bear);
printf("size is:%d\n", size);
return 0;
}
用gcc
test.c时,得出来的结构体的大小为16个字节,两个char型为2个字节,由于第二个char型后面为4个字节的enum型,所以按默认的4个字节对齐,前两个char型为4个字节。再加上两个enum,一个int型,所以总共16个字节。
然而在"#include <stdio.h>"下行加上#pragma pack(1)
编译运行后得到得结构体的大小为14个字节。因为这是按1个字节对齐,两个char型为两个字节,加两个enum,一个int共14个字节。
上面说的是按位对齐,而要把enum变为单个字节,则只需在上面的代码编译时,再加上-fshort-enums参数就行了:
gcc test.c -fshort-enums
运行后得到此结构体的大小只有8个字节了。上面的两个enum型就成就单字节的枚举了。
下面对-fshort-enums在gcc手册中的解释:
-fshort-enums
Allocate to an "enum" type only as many bytes as it needs for the
declared range of possible values. Specifically, the "enum" type will be
equivalent to the smallest integer type which has enough room.
Warning: the -fshort-enums switch causes GCC to generate code that is
not binary compatible with
code generated without that switch. Use it to conform to a non-default
application binary interface.
http://linux0818.bokee.com/viewdiary.179592916.html
[转贴]一个老程序员的心里话说到人的心坎
[1]
好好规划自己的路,不要跟着感觉走!根据个人的理想决策安排,绝大部分人并不指望成为什么院士或教授,而是希望活得滋润一些,爽一些。那么,就需要慎重安
排自己的轨迹。从哪个行业入手,逐渐对该行业深入了解,不要频繁跳槽,特别是不要为了一点工资而转移阵地,从长远看,这点钱根本不算什么,当你对一个行业
有那么几年的体会,以后钱根本不是问题。频繁地动荡不是上策,最后你对哪个行业都没有摸透,永远是新手!
[2]可以做技术,切不可沉湎于技术。千万不可一门心思钻研技术!给自己很大压力,如果你的心思全部放在这上面,那么注定你将成为孔乙己一类的人物!适可而止为之,因为技术只不过是你今后前途的支柱之一,而且还不是最大的支柱,除非你只愿意到老还是个工程师!
[3]
不要去做技术高手,只去做综合素质高手!在企业里混,我们时常瞧不起某人,说他"什么都不懂,凭啥拿那么多钱,凭啥升官!"这是普遍的典型的工程师的迂腐
之言。8051很牛吗?人家能上去必然有他的本事,而且是你没有的本事。你想想,老板搞经营那么多年,难道见识不如你这个新兵?人家或许善于管理,善于领
会老板意图,善于部门协调等等。因此务必培养自己多方面的能力,包括管理,亲和力,察言观色能力,攻关能力等,要成为综合素质的高手,则前途无量,否则只
能躲在角落看示波器!技术以外的技能才是更重要的本事!!从古到今,美国***,一律如此!
[4]多交社会三教九流的朋友!不要
只和工程师交往,认为有共同语言,其实更重要的是和其他类人物交往,如果你希望有朝一日当老板或高层管理,那么你整日面对的就是这些人。了解他们的经历,
思维习惯,爱好,学习他们处理问题的模式,了解社会各个角落的现象和问题,这是以后发展的巨大的本钱,没有这些以后就会笨手笨脚,跌跌撞撞,遇到重重困
难,交不少学费,成功的概率大大降低!
[5]知识涉猎不一定专,但一定要广!多看看其他方面的书,金融,财会,进出口,税务,法律等等,为以后做一些积累,以后的用处会更大!会少交许多学费!!
[6]
抓住时机向技术管理或市场销售方面的转变!要想有前途就不能一直搞开发,适当时候要转变为管理或销售,前途会更大,以前搞技术也没有白搞,以后还用得着。
搞管理可以培养自己的领导能力,搞销售可以培养自己的市场概念和思维,同时为自己以后发展积累庞大的人脉!应该说这才是前途的真正支柱!!!
[7]
逐渐克服自己的心里弱点和性格缺陷!多疑,敏感,天真(贬义,并不可爱),犹豫不决,胆怯,多虑,脸皮太薄,心不够黑,教条式思维。。。这些工程师普遍存
在的性格弱点必须改变!很难吗?只在床上想一想当然不可能,去帮朋友守一个月地摊,包准有效果,去实践,而不要只想!不克服这些缺点,一切不可能,甚至连
项目经理都当不好--尽管你可能技术不错!
[8]工作的同时要为以后做准备!建立自己的工作环境!及早为自己配置一个工作环境,
装备电脑,示波器(可以买个二手的),仿真器,编程器等,业余可以接点活,一方面接触市场,培养市场感觉,同时也积累资金,更重要的是准备自己的产品,咱
搞技术的没有钱,只有技术,技术的代表不是学历和证书,而是产品,拿出象样的产品,就可技术转让或与人合作搞企业!先把东西准备好,等待机会,否则,有了
机会也抓不住!
[9]要学会善于推销自己!不仅要能干,还要能说,能写,善于利用一切机会推销自己,树立自己的品牌形象,很必
要!要创造条件让别人了解自己,不然老板怎么知道你能干?外面的投资人怎么相信你?提早把自己推销出去,机会自然会来找你!搞个个人主页是个好注意!!特
别是培养自己在行业的名气,有了名气,高薪机会自不在话下,更重要的是有合作的机会...
[10]该出手时便出手!永远不可能有100%把握!!!条件差不多就要大胆去干,去闯出自己的事业,不要犹豫,不要彷徨,干了不一定成功,但至少为下一次冲击积累了经验,不干永远没出息,而且要干成必然要经历失败。不经历风雨,怎么见彩虹,没有人能随随便便成功!
Linux下的段错误的原因及调试
简而言之,产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址.
一般来说,
段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是由gdtr来保存的,他是一个48位的寄存器,其中的32位是保存由它指向的
gdt表,后13位保存相应于gdt的下标,最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别,指向的gdt是由以64位为一个单位的表,
在这张表中就保存着程序运行的代码段以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息。一旦一个程序发生了越界
访问,cpu就会产生相应的异常保护,于是segmentation fault就出现了.
在编程中以下几类做法容易导致段错误,基本是是错误地使用指针引起的
1)访问系统数据区,尤其是往 系统保护的内存地址写数据
最常见就是给一个指针以0地址
2)内存越界(数组越界,变量类型不一致等) 访问到不属于你的内存区域
解决方法
我
们在用C/C++语言写程序的时侯,内存管理的绝大部分工作都是需要我们来做的。实际上,内存管理是一个比较繁琐的工作,无论你多高明,经验多丰富,难免
会在此处犯些小错误,而通常这些错误又是那么的浅显而易于消除。但是手工"除虫"(debug),往往是效率低下且让人厌烦的,本文将就"段错误"这个内
存访问越界的错误谈谈如何快速定位这些"段错误"的语句。
下面将就以下的一个存在段错误的程序介绍几种调试方法: 1 dummy_function
(void)
2 {
3 unsigned char *ptr = 0x00;
4 *ptr = 0x00;
5 }
6
7 int main (void)
8 {
9 dummy_function ();
10
11 return 0;
12 }
作为一个熟练的C/C++程序员,以上代码的bug应该是很清楚的,因为它尝试操作地址为0的内存区域,而这个内存区域通常是不可访问的禁区,当然就会出错了。我们尝试编译运行它:xiaosuo@gentux
test $ ./a.out
段错误
果然不出所料,它出错并退出了。
1.利用gdb逐步查找段错误:
这种方法也是被大众所熟知并广泛采用的方法,首先我们需要一个带有调试信息的可执行程序,所以我们加上"-g
-rdynamic"的参数进行编译,然后用gdb调试运行这个新编译的程序,具体步骤如下:xiaosuo@gentux
test $ gcc -g -rdynamic d.c
xiaosuo@gentux test $ gdb ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/xiaosuo/test/a.out
Program received signal SIGSEGV, Segmentation fault.
0x08048524 in dummy_function () at d.c:4
4 *ptr = 0x00;
(gdb)
哦?!好像不用一步步调试我们就找到了出错位置d.c文件的第4行,其实就是如此的简单。
从这里我们还发现进程是由于收到了SIGSEGV信号而结束的。通过进一步的查阅文档(man
7
signal),我们知道SIGSEGV默认handler的动作是打印"段错误"的出错信息,并产生Core文件,由此我们又产生了方法二。
2.分析Core文件:
Core文件是什么呢?The default action of certain signals is to cause a
process to terminate and produce a core dump file, a disk file containing
an image of the process's memory at the time of termination. A list of the
signals which cause a process to dump core can be found in signal(7).
以 上资料摘自man page(man 5
core)。不过奇怪了,我的系统上并没有找到core文件。后来,忆起为了渐少系统上的拉圾文件的数量(本人有些洁癖,这也是我喜欢Gentoo的原因
之一),禁止了core文件的生成,查看了以下果真如此,将系统的core文件的大小限制在512K大小,再试:xiaosuo@gentux
test $ ulimit -c
0
xiaosuo@gentux test $ ulimit -c 1000
xiaosuo@gentux test $ ulimit -c
1000
xiaosuo@gentux test $ ./a.out
段错误 (core dumped)
xiaosuo@gentux test $ ls
a.out core d.c f.c g.c pango.c test_iconv.c test_regex.c
core文件终于产生了,用gdb调试一下看看吧:xiaosuo@gentux test $ gdb ./a.out
core
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
warning: Can't read pathname for load map: 输入/输出错误.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x08048524 in dummy_function () at d.c:4
4 *ptr = 0x00;
哇,好历害,还是一步就定位到了错误所在地,佩服一下Linux/Unix系统的此类设计。
接着考虑下去,以前用windows系统下的ie的时侯,有时打开某些网页,会出现"运行时错误",这个时侯如果恰好你的机器上又装有windows的编译器的话,他会弹出来一个对话框,问你是否进行调试,如果你选择是,编译器将被打开,并进入调试状态,开始调试。
Linux下如何做到这些呢?我的大脑飞速地旋转着,有了,让它在SIGSEGV的handler中调用gdb,于是第三个方法又诞生了:
3.段错误时启动调试:#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
void dump(int signo)
{
char buf[1024];
char cmd[1024];
FILE *fh;
snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());
if(!(fh = fopen(buf, "r")))
exit(0);
if(!fgets(buf, sizeof(buf), fh))
exit(0);
fclose(fh);
if(buf[strlen(buf) - 1] == '\n')
buf[strlen(buf) - 1] = '\0';
snprintf(cmd, sizeof(cmd), "gdb %s %d", buf, getpid());
system(cmd);
exit(0);
}
void
dummy_function (void)
{
unsigned char *ptr = 0x00;
*ptr = 0x00;
}
int
main (void)
{
signal(SIGSEGV, &dump);
dummy_function ();
return 0;
}
编译运行效果如下:xiaosuo@gentux test $ gcc -g -rdynamic f.c
xiaosuo@gentux test $ ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
Attaching to program: /home/xiaosuo/test/a.out, process 9563
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7ee4b53 in waitpid () from /lib/libc.so.6
#2 0xb7e925c9 in strtold_l () from /lib/libc.so.6
#3 0x08048830 in dump (signo=11) at f.c:22
#4 <signal handler called>
#5 0x0804884c in dummy_function () at f.c:31
#6 0x08048886 in main () at f.c:38
怎么样?是不是依旧很酷?
以上方法都是在系统上有gdb的前提下进行的,如果没有呢?其实glibc为我们提供了此类能够dump栈内容的函数簇,详见/usr/include/execinfo.h(这些函数都没有提供man
page,难怪我们找不到),另外你也可以通过gnu的手册进行学习。
4.利用backtrace和objdump进行分析:
重写的代码如下:#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
/* A dummy function to make the backtrace more interesting. */
void
dummy_function (void)
{
unsigned char *ptr = 0x00;
*ptr = 0x00;
}
void dump(int signo)
{
void *array[10];
size_t size;
char **strings;
size_t i;
size = backtrace (array, 10);
strings = backtrace_symbols (array, size);
printf ("Obtained %zd stack frames.\n", size);
for (i = 0; i < size; i++)
printf ("%s\n", strings[i]);
free (strings);
exit(0);
}
int
main (void)
{
signal(SIGSEGV, &dump);
dummy_function ();
return 0;
}
编译运行结果如下:xiaosuo@gentux test $ gcc -g -rdynamic g.c
xiaosuo@gentux test $ ./a.out
Obtained 5 stack frames.
./a.out(dump+0x19) [0x80486c2]
[0xffffe420]
./a.out(main+0x35) [0x804876f]
/lib/libc.so.6(__libc_start_main+0xe6) [0xb7e02866]
./a.out [0x8048601]
这次你可能有些失望,似乎没能给出足够的信息来标示错误,不急,先看看能分析出来什么吧,用objdump反汇编程序,找到地址0x804876f对应的代码位置:xiaosuo@gentux
test $ objdump -d a.out
8048765: e8 02 fe ff ff call 804856c <signal@plt>
804876a: e8 25 ff ff ff call 8048694 <dummy_function>
804876f: b8 00 00 00 00 mov $0x0,%eax
8048774: c9 leave
我们还是找到了在哪个函数(dummy_function)中出错的,信息已然不是很完整,不过有总比没有好的啊!
后记:
本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。
EMCV:可在DSP上运行的OpenCV
EMCV全称为Embedded Computer Vision Library,是一个可在TI
DM64x系列DSP上运行的计算机视觉库。EMCV提供了跟OpenCV完全一致的函数接口,通过EMCV,你可以轻松的将你的OpenCV算法移植到DSP,甚至不用改一行代码。
目前EMCV已经支持IplImage, CvMat,CvSeq等基本数据结构,
可使用cvCreateImage等创建和释放图像,以及contour检测等。
EMCV刚刚启动,希望得到您的代码贡献:
目前您可以通过subversion客户端获取源代码,源代码位于
https://emcv.svn.sourceforge.net/svnroot/emcv
在C6000系列DSP中使用EMCV,
请参考:http://www.opencv.org.cn/forum/viewtopic.php?f=9&t=4638
如何测试程序在DSP上的运行时间?
1、用CLOCK()准确吗?
2、用CCS上的工具,但如何使用?
在你要测试时间的程序的两端,用Project Toolbar上的Toggle profile
point按键,加上profile
print,像断点一样,不过是绿色的。然后在profiler菜单中选择Enable Clock和view
clock,在view clock窗口中可以看到程序运行的时间/周期(时钟)数。在view
clock窗口中第2行显示的时间就是程序从第1行所在位置到第2行位置的时间,也就是你要测定的时间。这是ti推荐的方法,但我发现数据不准确,比实际的要大。如果用profiler得到的数据比你的要求好要少的话,那就说明已经达到了要求,如果比你的大则比一定达不到要求。
周期测定可以利用DSP的定时器来实现!在你要测定开始的地方设定定时器并启动,在你结束的地方关闭定时器即可.不过要关闭中断哟?
用clock函数是可行的,尤其是优化以后的代码很难确定PROFILE的位置。你看一下.asm的输出就知道了,clock没有这个问题。有一点要注意,clock函数如果直接在DSP上跑时间是不准的,必须用load6x命令在DOS或命令行状态下加载,这样结果就准的多。当然,调用函数本身的开销也是要考虑的。
数汇编代码测程序运行时间的方法是不行的:)因为指令所耗费周期数是不一样的,并不是都是一个周期啊,你数指令条数判断运行时间不准确啊,而且小程序你还可以用数的方法,大的怎么办呢:)看看指令耗费周期数的大致规律啊
指令所耗费周期数规律:主要跟操作多少及有关系,简单的加减乘和逻辑运算一般是单周期,延迟跳转指令也是1周期,复杂的并行运算则因操作数据所在存储区(片内、外)而分成一周期和两周期,改变程序计数器的指令一般如跳转,返回等耗费4周期,软件陷阱则因操作多而需要5个周期。