前言
使用linux进行systemc的开发时经常出现core dump的文件，对于较大的项目vscode无法很快地进行debug，clion对makefile的支持不是很好，此时想到使用gdb进行调试并学习了一些基本的操作。以下的内容主要参考这篇博客和gdb debug的参考文档。
参考资料：
启动调试
GDB需要一个带有调试信息的可执行文件进行调试，因此编译过程中出现的错误无法使用GDB进行排除。通常对于C或者C++程序来说，在编译时加上-g参数可以保留调试信息，否则不能使用GDB进行调试。使用cmake时，可以在CMakeLists.txt文件中添加以下指令以支持GDB调试。
SET(CMAKE_BUILD_TYPE "Debug")
SET(CMAKE_CXX_FLAGS_DEBUG "$ENV{CXXFLAGS} -O0 -Wall -g2 -ggdb")
SET(CMAKE_CXX_FLAGS_RELEASE "$ENV{CXXFLAGS} -O3 -Wall")
如果程序不是自己编译的，那么如何判断文件中是否带有调试信息呢，这篇博客中给出了几种调试的方法。
- 使用gdb
$ gdb main
Reading symbols from main...
如果提示no debugging symbols found, 那么不可以使用gdb调试该可执行文件。 2. readelf
# main是可执行文件名称
$ readelf -S main | grep debug
- file查看strip状况
$ file main
如果输出内容为xxx stripped, 那么说明该文件的调试信息已经被去除，不能使用gdb调试。但是not stripped的情况不能说明该文件可以被调试。
启动调试
无参数程序
$ gdb main
(gdb) run
输入run命令即可运行程序。
有参数程序
$ gdb main
# world对应参数
(gdb) run world
# 使用set args
(gdb) set args world
(gdb) run
结束调试
使用quit指令。
调试core文件
本文最开始提到进行C++开发时经常遇到core dump的问题，这种情况下需要定位到具体的core dump的位置，目前了解到两种方法，一种是使用backward-cpp插件，在linux系统上可以打印出详细的报错信息，具体可以参考博客https://zhuanlan.zhihu.com/p/397148839；另一种就是利用gdb进行调试。
当程序core dump时会产生core文件，可以很大程度上帮助我们定位问题，但是前提是系统没有限制core文件的产生，使用ulimit -c查看
$ ulimit -c
0
如果结果是0，那么core dump后也不会有core文件留下，此时需要进行额外的设置
ulimit -c unlimied #表示不限制core文件大小
ulimit -c 10 #设置最大大小，单位为块，一块默认为512字节
调试core文件使用如下命令
gdb 程序文件名 core文件名
断点设置 & 变量查看
关于断点设置和变量查看的相关内容可以查看这篇博客https://www.yanbinghu.com/2019/04/20/41283.html，后续有时间的话会对相关内容加以整理。
目前调试主要还是借助IDE，对于一些core dump或者没有IDE的情况，gdb的调试将不可或缺，因此这里简单学习后加以记录。