GDB (The GNU Project Debugger)是 Linux 系统下调试 C 和 C++ 程序的主要神兵。Vim教程网(https://vimjc.com)介绍多种方式下使用 GDB 启动进程调试的方法和命令。
要使得 C 和 C++ 程序能在 GDB 下正常进行调试，必须在程序编译期间把基本的调试信息(如变量名、函数名、函数调用堆栈等)添加到可执行文件中。gcc、cc、g++ 等编译器可通过编译参数 -g 指定添加调试信息。
当使用 GDB 加载不包含调试信息的二进制文件或进程时，GDB终端会提示错误信息：”no debugging symbols found”。
一、GDB调试未执行程序
对于本地的某个二进制文件 demo ( GDB 也支持远程调试)，若其启动时不需要命令行参数，则可以在shell下使用命令 gdb demo 进入 GDB，并输入 run (缩写形式 r) 启动对demo的调试。
若 demo 程序启动时需要命令行参数，则可以在使用 gdb demo 命令进入 GDB 后，使用命令 run arg1 arg2... 提供命令行参数并启动对 demo 程序的调试。
二、GDB调试运行中程序
使用 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 调试多进程和多线程，后续会有独立的文章进行详细介绍。
三、GDB调试core文件
当程序在 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 文件的具体方法和命令，请关注Vim教程网(https://vimjc.com)后续 GDB 系列的后续文章。
PS：使用 quit (缩写形式 q) 可退出 GDB。
转自：https://vimjc.com/debug-program-with-gdb.html
