以前学的时候在书上看过GDB调试，那时候就觉得，这玩意相比vs的调试太复杂太麻烦了，一堆的指令和命令，当时是一脸的嫌弃。 当我深入学习linux之后我发现用 shell命令是一个既成的事实，要想学好linux只能去学习各种shell命令。最近用GDB找到一份工程的段错误，就是真香打脸。
为什么要用GDB呢？ 其实是在程序出现段错误的时候用GDB去事后调试。为什么说是事后调试？在调试之前我们就正常执行自己的程序，在程序执行完之后内核会返回一个core 文件，我们再用 gdb去看这个core文件，加入 就可以一些指令就可以看见里面的段错误的位置。
首先我们要看一下自己的系统里有没有gdb调试工具在终端输入which gdb可以看见返回，一般默认是有装gdb的，如果没有的话自己百度搜索装一下，因为我也没有装过哈哈哈哈
为了测试，我就自己编写一个简单的测试程序，当然这个程序只要是你稍微有点编程功底的你都可以看得出他的错误
#include <stdio.h>
void PrintTest(void)
{
int *p;
*p = 1111;
printf("*p = %d\n",*p);
return;
}
int main(void)
{
PrintTest();
return 0;
}
然后编译，直接正常编译gcc hello.c -o hello，这样就会生成一个hello的执行文件，执行这个文件./hello就发现段错误出现了。
如果只是上面的程序大家肯定是可以看出来错误在哪里，但是如果是一个很大的工程， 几十万上百万的代码呢。这个时候就用GDB。在用GDB之前有一点要特别说明。在编译的时候一定要用编译模式去编译， 所谓的编译模式就是在编译的时候加上-g,只有加上-g之后才会有调制信息，这个很重要，切记切记。如gcc hello.c -o hello -g
另外还有一点需要注意，在加上-g编译之后生成的可执行文件，在执行完之后会生成一个core文件，这个core文件在可执行程序的同一级目录下。但是需要注意，不同的系统的环境设置不一样，所以会有差别。我用Ubuntu系统在正常情况下是不会生成core文件的。这是因为Ubuntu系统 在默认的情况下出现段错误之后内核默认core file的大小是0，就不输出这个文件。我们需要去修改这个配置使内核可以输出这个文件。
首先我们在终端输入ulimit -a，这个命令就是查看当前资源极限，具体可以百度查看，显示如下
看第一项，默认core file size是0，所以我们执行完之后看不到core文件。一般来说core文件会比较大，所以这个大小我们直接设置成不限制大小就可以，输入ulimit -c unlimited,再输入ulimit -a可以看见第一项变化了
这时候执行./hello在同级目录可以看见core文件
这个时候输入命令gdb hello core（这里的hello是可执行文件，不同的人编译的名字不一样）。有些博主写的调试命令是gdb -q hello core我试过在Ubuntu上都可以
可以看到段错误出现的地方在*p = 1111;，输入bt还可以看见上下级的调用关系。如果想退出就按Quit回车就退出了
如果想在开发板上调试的话，需要把gdb调试工具拷贝到开发板上，但是需要注意一点，因为core文件很大，我们设置成不受限制的大小，一般都设置成不受限制。所以最好是通过nfs挂载你的程序到开发板，不然开发板可能存不下core文件，然后gdb和你的程序在同一级目录。当然你的程序肯定还得是debug模式的（编译的时候加-g）。操作跟上面基本一致，然后生成core文件之后需要输入./gdb XXX core(注：这里的XXX是你的可执行文件，注意跟在Ubuntu上不一样，这里要在gdb前面加./。gdb本身也是一个程序的。)
参考链接：https://blog.csdn.net/xja31415/article/details/52777509
这位博主写得不错，他是在Ubuntu上实现的，我刚开始是参考他在开发板上实现的，然后做了以上总结。感谢！