对于一个.C程序说 ，编码完成后 ，要经过 预处理 编译 汇编 链接等过程最后生成可以执行的二进制文件. // 下面的filename代表 文件名称 首先先复习一下整个过程 a. 预处理

宏展开，去注释，将源代码展开 gcc -E [filename.c] -o [filename].i

b. 编译

语法语义检测, 生成汇编代码 gcc -S [filename.i] -o [filename].s

c. 汇编

生成二进制文件 gcc -c [filename].s -o [filename].o

d. 链接

链接分为 静态链接 和 动态链接 默认为动态 静态 gcc [filename].o -o [filename] -static

静态 : 直接把所需要的库中的可执行指令全部链接到代码中, 这样的程序在运行的时候不用依赖其他的库可以直接运行. 但是有个问题 会导致整个可执行程序很大 动态: 运行的时候需要依赖外部的库, 一般都将外部的库和exe文件放在一起 , 也可以自己设定寻找路径, 整个exe 程序比静态链接的exe文件小， 还有一个好处 如果一个库的代码更新 , 直接编译那一个库就行 , 而不需要像静态的整个编译. gcc 默认使用动态编译

查看文件链接属性 file [namefile] 查看链接了那些库 ldd [namefile]

GBD 调试

GDB调试分为

运行前调试： 调试可执行程序 运行中调试： 调试进程 运行之后调试: 调试core文件

运行前调试 ： 需要在所编译的源文件中加上 -g 选项生成debug的文件 如果不是debug版本 那么会提示( no debugging symbols found ) 没有找到到调试符号 注意 -g 选项只有在 .c ，.i ， .s 文件下才有用 在已经生成二进制文件后 -g选项 无效 例如: 下面的例子 我们用 .o文件生成 debug文件 但是, 用GDB 调试的时候, 提示没有相关的调试信息. GDB 调试命令

l (list) ： 查看源代码 r (run）: 程序跑起来 b [行号] ：打断点 b [源码文件名称]:[行号] 跨文件打断点 info break : 查看断点信息 disable b [断点序号] : 使断点失效 enable b [断点序号] : 使断点生效 // b 加不加都行 delete breakpoints [断点序号] : 删除断点 n(next) : 逐过程 s(step) : 逐语句 c(continue) : 继续执行 p[变量名称] : 打印作用域这个名称变量的值 watch[变量名称] ： 一直监视这个值 // 需要这个作用域中有这个值 i locals ： 查看当前作用域中的临时变量 display : 跟踪变量的值 // watch 会更好一些 因为还可以打出旧值 whrer , bt ： 可以查看调用堆栈 // 堆栈从下往上看 main 在最下面 delete breakpoints [num] ： 删除断点 delete breakpoints ：删除所有断点

事中调试

在程序运行起来后没有加 gdb -p[进程号] bt 可以查看调用的堆栈

事后调试

gdb 可执行程序 coredump文件 备注 : 这是用于检测程序为什么崩的 , 当一个程序崩掉后， 系统会生成一个coredump 文件 ， 然后用gdb debug程序 coredump 这个命令 来调试这个程序 这样可以快速定位错误的位置 而如果用普通的方式只能看到函数堆栈，不能确定代码出现问题的地方