【学习总结】gcc和gdb

目录

<>

vim、gcc、gdb：

• gcc：

  • gcc和g++是c/c++的linux系统集成的编译器，源文件的后缀应为 .C/.cpp/.c++/.cc等
  • 编译器可以将C、C++等语言源程序、汇编程序编译、链接成可执行程序。

• gdb：

  • 是 GNU 开发的一个Unix/Linux下强大的程序调试工具。

gcc

基本格式：gcc [options] file1 file2... //若不加入参数，则按默认参数依次执行编译、汇编和链接操作，生成的可执行文件名为 a.out
常用参数：-E //只执行预处理操作
　　　　　-S //只执行到编译操作完成，不进行汇编操作，生成的是汇编文件(.s 或 .asm),内容为汇编语言
　　　　　-c //执行编译和汇编，但不进行链接，即只生成可重定位目标文件(.o),为二进制文件，不生成完整的可执行文件
　　　　　-o filename //将操作后的内容输出到filename指定的文件中
　　　　　-static //对于支持动态链接的系统，使用静态链接而不是动态链接进行链接操作
　　　　　-g　　　　　　　　　 //编译时生成debug有关的程序信息(供gdb使用)
　　　　　--save-temps //生成编译过程的中间结果文件(包括预处理文件(x.ii)、汇编代码(x.s)、目标文件(x.o)和最终的可执行文件)

　　　　　-I PATH //在PATH指定的目录下寻找相关的include文件，参数中间不加空格
　　　　　-lxx //其中xx为指定函数库，对于Linux环境下的函数库，静态库后缀为.a,动态库后缀为.so，一般库名为libxx.a或libxx.so,如加入libm.so库，则使用参数-lm(去除lib和后缀.a\so)
　　　　　-L PATH //在PATH指定的目录下寻找相关的库文件，即-lxx指定待链接的库，-L指定寻找该库的路径。不指定时搜索默认的库函数路径。

　　　　　-std=xx //指定编译使用的语言标准,如 -std=c++11 使用 c++11 标准
　　　　　-x language //指定待编译文件的语言，而不是由编译器根据文件后缀自行判断。即默认情况下gcc根据文件后缀判断使用的编程语言。例如使用文件名hello作为源文件名是不合适的，应使用hello.c
　　　　　
　　　　　-Wall //输出一些简单的错误以及一些可能存在问题的警告
　　　　　-Wextra //输出-Wall不包含的警告等
　　　　　-Werror //将警告视为错误输出
　　
　　　　　-Wl,option　　　　　　　　　 //通过该选项将参数 option 作为后续链接器 ld 使用的参数
　　　　　-Wl,rpath=/path/to/lib　　//为链接器指定一个非默认的运行时库的搜索路径，运行采用了该选项编译的程序时，链接器会在-rpath 指定的目录中搜索所需的 so 库文件，以将其载入内存中
　　　
　　　　　-D name=definition //加入宏定义，若不指定def，则默认为1
　　　　　-O1、-O2　　　　　　　//规定编译器的优化等级，优化级数越高执行效率一般越好，但是优化会改变原有程序结构，使得其汇编不易理解

　　　　　//一些进行缓冲区溢出实验时可能需要的选项
　　　　　-fstack-protector-fno-stack-protector　　//是否开启堆栈保护，这里的保护是在返回地址之前加入一个验证值来确保返回地址不被破坏
　　　　　-z execstack 　　　　　　　　　　　　　　　　　//启用可执行栈，默认是禁用的
　　　　　//（echo 0 >/proc/sys/kernel/randomize_va_space 关闭地址随机化，这是一个单独的命令,操作需要root权限）

GDB

　　gdb是Linux下一款功能强大的调试工具，它既能在反汇编过程中充当一件称手的工具，也能在程序debug过程中为为程序员提供帮助，其唯一美中不足的是在Linux环境下没有图像界面(当然没有功能的封装也是其功能强大的原因之一，而且现在的ddd也提供了GUI)。这里主要记录笔者从一些学习指导中学习的关于gdb命令和用法的总结。

　　

为什么要使用GDB？

　　1.在Windows环境下，许多IDE以图形界面提供类似gdb的功能，一般也较为好用。但是一方面，gdb提供给使用者更大的自由，另一方面gdb也是目前几乎所有Linux发行版本的自带软件，简单易得；

　　2.调试程序时尽量减少对诸如printf等输出函数的依赖。许多作者给出的解释是重新修改代码和编译是一件麻烦的差事。这一点笔者起初也并不理解，觉得上述操作确实不算麻烦(...)。后来发现，对于一个单一文件，代码不超过100行的文件，上述操作确实在可接受范围。但对于文件众多，工程量巨大的项目，修改代码、重新编译文件是一件极其耗时且麻烦的操作。如果在Windows环境下进行大工程的debug所需要的修改、重编译所带来的频繁鼠标或快捷键操作还不能使你回心转意的话，相信我，在Linux的命令行模式下进行相同的操作会让你有所改变的；

　　3.习惯是逐渐养成的，不论好坏都是。或许只有逐渐在看起来不那么方便的GDB中锻炼起来，你才能在无论什么编译环境中debug的得心应手，可能那时，你会嫌弃图形界面提供的工具不够给力的；

调试策略

　　无论进行何种调试工作，大体的调试策略都类似：使用二分法的方式对错误地点进行定位；使用断点(breakpoint)，使程序运行至断点处时停止以便观察程序状态；使用单步执行，使程序运行一条指令后停止，从而观察数据的变化情况和程序控制流；对一个变量预设特定的值，跟踪其在程序运行中的变化规律等等。根据二八定律，使用20%的GDB指令，一般就可以解决80%的程序bug。这里介绍的是能够常规使用GDB的命令，更多高级或特殊指令，可以参考GDB官方文档Degugging with GDB。

　　为了更好的使用gdb的调试功能，在编译程序时需加入 -g 选项，由编译器生成某些用于调试的信息。

　　

　　GDB常用命令(此部分译自 Guide to Faster，Less Frustrating Debugging，细节有改动)

gdb设置断点流程：

• xxx: gdb + 空格 + 文件名 -- 进入gdb
• (gdb) run + 回车 -- 运行程序并显示运行结果
• (gdb) break + 某位置 -- 在某位置处设置断点，例如break main--在main函数处设置断点
• (gdb) run + 回车 -- 再次运行，并在断点处停下来 （注：显示程序位置、断点信息、断点处代码）
• (gdb) next + 回车 -- next键入后才会开始执行 （注：显示下一行尚未执行的代码）
• (gdb) print + 某变量名 -- 查看此时某变量名的值 （注：print结果以美元符号$开头+顺序数组+变量值）
• (gdb) next..... -- 继续执行等等
• (gdb) continue + 回车 -- 取消断点
• (gdb) run -- 又停在断点处
• (gdb) next
• (gdb) step -- 进入某函数
• (gdb) list -- 查看gdb上下文，即代码
• (gdb) backtrack -- 回溯位置
  • 井号0：现在的位置
  • 井号1：之前从哪里来的位置
• (gdb) q -- 退出debug

END