在使用 gdb 调试程序时，很多人一上来就敲 gdb ./myprogram，结果发现断点加不上、变量看不到、源码也对不上行号。这种情况，大概率是因为你还没真正“编译成功”。
编译通过 ≠ 编译成功用于调试
写完代码后运行 gcc main.c -o myprogram，看起来没报错，程序也能跑，但这并不代表适合用 gdb 调试。默认编译生成的可执行文件不包含完整的调试信息，gdb 根本“看不懂”你的源码结构。
比如你在 IDE 里习惯了点一下“调试”，背后其实自动加了调试选项。而命令行下必须手动指定，否则就是白忙活。
必须加上 -g 编译选项
正确做法是用 -g 参数让编译器把变量名、行号、函数结构等信息一起塞进可执行文件：
gcc -g main.c -o myprogram这样生成的 myprogram 才能被 gdb 正常加载。启动后输入 list 能看到源码，设断点会显示“Breakpoint 1 at 0x401123: file main.c, line 10”，这才说明调试环境准备好了。
优化选项可能干扰调试
有时候即使加了 -g，gdb 还是跳来跳去，甚至提示“value optimized out”。这是因为你同时用了 -O2 或 -O3 这类优化参数。
编译器为了提升性能，可能会删掉中间变量、合并函数调用，导致源码和实际执行流程对不上。这时候应该关掉优化：
gcc -g -O0 main.c -o myprogram开发阶段优先保证可调试性，功能没问题后再考虑性能优化。
检查是否真的生成了调试信息
如果你不确定当前程序有没有调试信息，可以用 file 命令看看：
file myprogram输出中如果包含 “not stripped”，并且提到 “debug_info” 相关内容，基本就没问题。如果是 “stripped”，说明调试符号已经被剥离，gdb 拿它也没办法。
还有一个方法是直接在 gdb 里输入 info sources，能看到所有关联的源文件列表，就说明调试信息存在。
常见错误场景
有人改完代码忘了重新编译，直接进 gdb 调试旧版本，折腾半天发现断点根本不会触发——因为代码和二进制不匹配。这种问题在团队协作或远程服务器上特别容易发生。
建议养成固定流程：
修改代码 → 保存 → 清理（make clean）→ 带 -g 重新编译 → 启动 gdb。
哪怕只是改了一行，也要走一遍完整编译。别图省事，省出来的时间最后都花在排查奇怪问题上了。