必须先安装gdb再用-g编译程序，否则无法设断点、list看不到源码、print读不到变量；Ubuntu/Debian用sudo apt install gdb，CentOS/RHEL 7用sudo yum install gdb，8+用sudo dnf install gdb，装完运行gdb --version验证。
必须先装 gdb，再用 -g 编译程序，否则断点根本设不进去、list 看不到源码、print 读不到变量——这是绝大多数人卡住的第一步。
安装 gdb 前先确认系统类型
不同发行版命令不同，错用 yum 装在 Ubuntu 上会失败，反之亦然：
- Ubuntu / Debian：
sudo apt update && sudo apt install gdb - CentOS / RHEL 8+：
sudo dnf install gdb - CentOS 7 / RHEL 7：
sudo yum install gdb - Fedora：
sudo dnf install gdb
装完运行 gdb --version，能看到输出即成功。如果提示 command not found，说明没装上或 PATH 没生效。
编译时漏掉 -g，gdb 就是“睁眼瞎”
默认 gcc test.c -o test 生成的是 release 版本：没有行号、没有变量名、没有函数边界。gdb 加载后执行 list 会报 No symbol table is loaded，break main 会提示 Function main not defined。
正确做法是显式加 -g：
gcc -g test.c -o test- 如果是 C++：
g++ -g test.cpp -o test - 配合优化选项（如调试时想看实际汇编）：
gcc -g -O0 test.c -o test（-O0禁用优化，避免变量被优化掉）
注意：-g 和 -O2 可共存，但高优化下局部变量可能消失、内联函数无法单步进，调试体验会打折。
设断点的三种常用写法和典型错误
断点设错位置，程序跑飞或压根不中断，常见于路径、函数名拼错或未加载符号：
- 在
main函数开头设断点：break main（不是break _main或break Main） - 在当前文件第 15 行设断点：
break 15（前提是已用list确认当前文件上下文） - 跨文件设断点（如
utils.c第 8 行）：break utils.c:8（冒号不能写成空格或点） - 错误示例：
break test:15（没扩展名）、break ./test.c:15（路径多余）、break my_func()（括号非法）
设完用 info breakpoints 确认状态，Num 列显示编号，Type 是 breakpoint，What 显示具体位置才算成功。
运行后卡住不动？检查是否真停在断点上
输入 run 后终端没反应，不是 gdb 卡了，大概率是：程序没触发断点、断点被跳过、或 stdin 阻塞等待输入。
- 先用
info registers或bt（backtrace）看当前执行位置，确认是否已暂停 - 如果
bt报No stack.，说明程序根本没跑起来，检查可执行文件权限或是否被 SELinux 拦截 - 若程序有
fgets、scanf等读输入，run后需手动敲回车或输入数据，它才继续 - 想让程序自动带参数运行：
run arg1 arg2；重定向输入：run
真正调试时，next（不进函数）和 step（进函数）的区别常被忽略：对库函数盲目 step 会陷进 glibc 源码里，此时该用 next 或 finish 快速跳出。
