GDB入门教程之如何使用GDB启动调试

写在前面：今天开始尝试写写除Vim外的其他内容，仍然是以技术为主，可能涉及的内容包括Linux、正则表达式、gdb、makefile等内容，不知道小伙伴们有没有兴趣看呢？不管如何，也算是我自己的知识沉淀吧~ 我把公众号改名了，你们猜猜新名字是啥？

GDB (The GNU Project Debugger)是 Linux 系统下调试 C 和 C++ 程序的主要神兵。本文介绍多种方式下使用 GDB 启动进程调试的方法和命令。

要使得 C 和 C++ 程序能在 GDB 下正常进行调试，必须在程序编译期间把基本的调试信息(如变量名、函数名、函数调用堆栈等)添加到可执行文件中。gcc、cc、g++等编译器可通过编译参数 -g 指定添加调试信息。

当使用GDB加载不包含调试信息的二进制文件或进程时，GDB终端会提示错误信息："no debugging symbols found"。

对于本地的某个二进制文件 demo ( GDB 也支持远程调试)，若其启动时不需要命令行参数，则可以在shell下使用命令 gdb demo 进入 GDB，并输入 run (缩写形式 r) 启动对demo的调试。

若 demo 程序启动时需要命令行参数，则可以在使用 gdb demo 命令进入GDB后，使用命令 run arg1 arg2... 提供命令行参数并启动对demo程序的调试。

使用GDB调试正在运行的程序时，必须先找到该程序运行在操作系统中的进程号 (PID)。可以使用 Linux 命令 ps-ef|grep-w demo 、 ps-aux|grep-w demo 或 pidof demo获取到 demo 进程当前的进程号。

获取到待调试的目标进程号后 (假设为 pid )，可以使用 gdb 命令进入 GDB 终端，并使用 attach pid 的方式启动对当前正在运行的 demo 进程的 GDB 调试。

也可以使用 gdb-p pid 命令直接进入 GDB 并启动对该进程的调试。

对于使用多线程模式的进程，可以在 GDB 中使用 info threads 命令显示当前进程中所有线程的基本调试信息，包括：GDB 分配的线程ID、线程堆栈等。线程列表中，GDB 线程 ID 左侧的 * 表示当前真正被调试的线程。

可通过 thread tid 命令切换和启动对 GDB 线程号为 tid 的线程进行调试。关于使用 GDB 调试多进程和多线程，后续会有独立的文章进行详细介绍。

当程序在 Linux 系统下发生异常崩溃(如段错误)时，内核会将该应用程序在崩溃发生时的内存数据、程序调用堆栈等核心信息转存到磁盘，这种功能称之为 core dump，中文可翻译为 核心转储。

core dump 是程序异常退出时的内存快照，是异常发生后对程序进行现场还原和故障排查的关键线索。Linux 进程 core 掉可以说是所有 C 和 C++ 程序员接触最频繁而又最不想碰到的问题。

可通过 ulimit-c 查看和指定 core 文件的大小，通过修改 /proc/sys/kernel/core_pattern 文件可指定 core 文件保存在本地磁盘中的路径和文件名格式。

GDB 对 core 文件的分析和调试提供了非常强大的功能支持，可使用 gdb demo/data/core/xxx 启动对 demo 进程某次产生的core文件 /data/core/xxx 的分析和调试，也可以使用

gdb-c/data/core/xxx 加载和分析 core 文件。

GDB 正常加载 core 文件后，便可以使用 backtrace (缩写形式 bt) 显示程序异常退出时刻的函数堆栈情况，再使用 frame、 print、 up、 down、 where 等命令对异常现场进行详细分析。

为了让程序产生 dump ，将 demo.cpp 中的输出语句 printf("%s: %d\n",(char*)ptr,array[i]); 改成 printf("%s: %s\n",(char*)ptr,array[i]); 后在编译时加入 -w 参数忽略掉警告后重新生成 demo 可执行文件。

关于 GDB 调试程序和 core 文件的具体方法和命令，请关注公众号 GDB 系列的后续文章。

PS：使用 quit (缩写形式 q) 可退出 GDB。