gdb源码行号错位主因是调试上下文不匹配：编译未加-g或启用-o2等优化导致指令与源码映射失准；文件换行符为dos格式（含^m）亦会扰乱行号解析。
源码行号错位不是GDB本身出错，而是调试上下文不匹配导致的——最常见原因是目标机上运行的二进制文件和你本地GDB加载的符号文件（含源码路径、行号映射）对不上。
编译时没加 -g 或用了优化选项
没有 -g，GDB 根本看不到行号信息；用了 -O2 这类优化，编译器可能把多行语句合并、内联、删掉无用变量，导致源码行和机器指令无法一一对应。
- 确认编译命令是
gcc -g -O0，不是-O2或-Os - 在目标机上检查可执行文件是否真含调试段：
readelf -S ./program | grep debug，应有.debug_*段 - 如果用 Makefile，确保所有
.o和最终链接都带-g，别只在某一步加
源文件路径不一致（尤其跨主机/IDE）
GDB 加载符号后，会按编译时记录的绝对路径去找源文件。如果你在 Ubuntu 上编译，再把二进制拷到嵌入式设备上调试，而本地 GDB 启动时当前目录或 directory 设置不对，list 就会显示 “No such file” 或跳到错误行。
- 启动 GDB 后先执行：
directory /path/where/you/compiled/the/source - 或者编译时用
-fdebug-prefix-map重写路径（推荐）：gcc -g -fdebug-prefix-map=/home/user/project=/project，然后本地 GDB 只需把源码放/project下即可 - 用
info sources查看 GDB 当前识别到哪些源文件路径，比对是否和你本地实际路径一致
文件换行符是 DOS 格式（^M）
Windows 编辑保存的源文件传到 Linux 目标机或开发机，每行末尾多了 \r（即 ^M），GCC 编译时会把它当普通字符处理，导致行计数偏移，GDB 解析行号表时就全乱了。
- 在源码所在机器上运行：
file your_source.c，若输出含CRLF或with CRLF line terminators，就是 DOS 格式 - 快速修复：
dos2unix your_source.c（没安装就sudo apt install dos2unix） - 或用 Vim 打开后执行：
:set ff=unix<enter> :wq</enter>
真正难排查的是混合场景：比如你用 VS Code 在 Windows 写代码 → 用 WSL 编译（但忘了 -g -O0）→ 把二进制和 .debug 文件一起传到 ARM 板 → 本地 GDB 加载时又没设 directory。这时候行号错位往往不是单一原因，得一层层排除——优先验证 readelf -S 和 info sources，这两个命令能立刻告诉你问题出在符号生成端还是路径加载端。
