开发工具gdb

gdb在Linux下负责程序的调试。

gdb相较于vs2019的调试，是不方便的。图形化界面调试确实是一种进步的现象。

先编写一个简单的程序，如果不支持在for循环中定义变量，要在编译指令后面加上-std=c99选项。

要编译的文件和要生成的文件位置要正确，位置反了的话源代码就没了。

用gdb调试只需要在当前路径下输入gdb指令，后面跟上要调试的可执行文件。不是源代码文本文件，是可执行文件。

但是发现no debugging symbols found，也就是说默认生成的可执行文件是不可调试的。quit退出。

vs2019中C语言程序的发布方有两种：debug和release，默认情况下是debug，所以默认情况下就可以调试。而在Linux中，默认情况下是release版本。如果要生成debug版本的可执行程序，需要加上选项：-g

debug发布会提供一些调试信息。而release发布是没有调试信息的。从文件大小也能看出debug发布的可执行程序比release发布的可执行程序大。

如何证明调试信息的存在？

命令：readelf -S [可执行程序]

可以以段的方式读取可执行，可以让每个可执行程序的结构信息显示出来。

但是看不懂，筛选一下：

add_g存在debug相关信息，而add中则不存在。所以debug发布才会比release发布大一些。

gdb进入调试后在gdb命令行输入l（list的简写）会显示代码：

默认从第4行显示，想要从第1行显示输入l 0：

l main则可以将包含main的代码显示出来：

从中可以观察到l只能显示10行代码。

直接按回车则会显示上一条命令的下一段10行代码。不足10行就有多少显示多少，没有就说明没有了。

打断点: b（breakpoint的简写）后面加上断点的行数

完成打断点后会显示断点信息。每次使用gdb都需要重新打断点。

断点信息表示：断点1，在文件add.c的第15行

如果想要查看断点：info b

在vs2019中，f9打断点，打好断点后，一运行就会立刻执行到断点处停止。

在Linux下，运行：r（run的简写）

最好打两个断点，一个断点可能会出什么错。

想要看此时start的数据：p（printf的简写）start，还可以看start的地址：

当程序在第一个断点处停止时，再次r，程序会直接结束，使用s（step简写）指令，逐语句(vs2019中f11)执行语句。断点在AddToTop函数所在行，如果不想进入函数，就要逐过程(vs2019中f10)执行，使用指令n（next简写）指令。

如何删除断点？

使用d指令（delete的简写）：d + 断点编号，不是断点所在行数。

看当前函数的调用堆栈则使用bt指令

Linux下查看变量的值可以使用p指令，但p指令只能显示某个时间点变量中存的值，如何让Linux程序中的变量常显示？

使用指令display + 变量名，等价于vs2019下的监视窗口。

每个常显示变量前有一个序号，如果不想常显示某个变量，就使用指令undisplay + 变量前的编号。

假设我现在在调试一个循环语句，调试了一些后发现循环没有问题，现在不想调试循环了。如何跳出循环？

使用until指令，until + 跳转的代码行数，中间的代码会自动执行完。

从一个断点处运行到下一个断点处，需要使用c指令（continue的简写）

如果进入一个main函数内的函数栈帧，使用finish指令可以立即执行完当前函数，并停止。

在main函数下使用finish指令没有用：

直到显示下列信息，程序才算结束：

gdb的使用比较复杂，繁琐。所以程序员最不喜欢的两件事之一就是调试代码，另一件是写项目相关的文档。

顺便说一下，不要想着复制代码到vs下调试，后面一些代码要用到调用系统的接口，只能在Linux才能运行。不过后面的代码基本不会出错，所以也不要有太大压力。