源码行号对不上是因为gdb从.debug_line读取的是绝对路径，调试时若路径不一致（如跨机器、docker、ci构建），gdb会加载错误版本的同名文件，导致显示内容与预期不符；可用directory或substitute-path命令修复路径映射，并通过info source和info line $pc验证。
源码行号对不上，基本可以确定是编译时的源文件路径和当前调试环境中的路径不一致，不是代码改了但没重新编译，也不是 -g 没加——这两类问题会直接导致 list 报错或显示乱码，而行号偏移是“能显示源码，但显示的不是你预期那行”的典型症状。
为什么 list 显示的行号和实际文件对不上
GDB 在编译阶段从 .debug_line 段读取的是**绝对路径**（比如 /home/alice/project/src/main.c）。如果你把可执行文件拷到另一台机器、或在不同目录下打开同一份代码，GDB 仍会按原始路径去加载文件——结果就是它找到了某个同名文件，但内容和编译时的版本不一致，行号自然错位。
- 常见于：开发机编译 → 测试机调试；Docker 构建后本地调试；CI 编译产物拉回本地 debug
- 不会触发报错，
list看起来“有代码”，但第 42 行可能是空行、注释，甚至属于另一个函数 -
info source能看到 GDB 实际加载的源文件路径，这是第一手判断依据
用 directory 命令重定向源码搜索路径
directory 是最轻量、最常用的修复手段，它告诉 GDB：“别去原来那个绝对路径找了，优先查我给的这些目录”。
- 添加单个目录：
directory /path/to/your/src - 添加多个目录（顺序重要，前面的优先匹配）：
directory /src/v2 /src/v1 ./ - 查看当前生效的源码路径列表：
show directories - 注意：该设置只在当前 GDB 会话有效；如需持久化，写进
~/.gdbinit，例如：directory /home/me/project/src
用 substitute-path 修复路径映射关系
当原始路径和当前路径存在固定前缀差异（比如编译时是 /jenkins/workspace/app/src/，你本地是 /home/user/app/src/），substitute-path 比 directory 更精准，它做的是字符串替换而非路径搜索。
- 语法：
set substitute-path <em>from-path</em> <em>to-path</em> - 示例：
set substitute-path /jenkins/workspace/app/ /home/user/app/ - 效果：GDB 遇到任何以
/jenkins/workspace/app/开头的源码路径，自动替换成/home/user/app/后再尝试打开 - 查看当前所有替换规则：
show substitute-path - 这个设置也支持写入
~/.gdbinit，适合 CI/CD 流水线场景
检查并确认调试信息是否真的匹配当前源码
路径修对了，但行号还是不对？那很可能是你正在看的源码和编译时用的根本不是同一份。尤其要注意：
- Git 分支是否一致？
git status和git log -1对比编译时的 commit - 是否启用了预编译头（PCH）或构建缓存，导致部分 .c 文件没被重新编译？试试
make clean && make -j -
readelf -wl ./a.out | grep -A2 "Line Number Entries"可粗略验证调试信息里记录的路径是否合理 - 如果用 IDE（如 VS Code + C/C++ extension）调试，它可能自动做了路径映射，但命令行 GDB 不会——别默认两者行为一致
最麻烦的情况是：你手头的源码确实和二进制不匹配，但又找不到原始版本。这时候别硬调，先用 info line *$pc 查当前指令对应的源码位置，再结合 disassemble 看汇编，靠逻辑反推——毕竟行号只是辅助，指令流和寄存器状态才是真相。
