GDB中source-file路径不生效，主因是调试符号记录的原始路径与当前环境不匹配：set substitute-path仅做前缀字符串替换且须完全匹配，directory仅对相对路径有效；若符号表存绝对路径而未用substitute-path正确映射，或缺失目标平台调试符号包，均会导致list失败或断点失效。
为什么 source-file 路径不生效？
你执行了 set substitute-path /old/path /new/path 或 directory /path/to/src，但 list 仍显示“No such file”，或断点打在源码行却提示 Function not defined —— 这通常不是路径写错，而是调试符号里记录的原始路径根本没被 GDB 找到匹配项。GDB 不会自动递归搜索，它只按符号表里存的绝对路径（编译时的 -I 和工作目录）去查，一旦二进制是在另一台机器上编译的，路径就大概率对不上。
set substitute-path 的真实行为
这个命令不是“添加搜索路径”，而是做字符串前缀替换：把符号表里记录的路径开头的 /old/path 替换成 /new/path。它只作用于调试信息中已存在的路径，且必须完全匹配前缀。
- 如果编译时用的是
gcc -g -I/home/build/include main.c，符号表里可能存着/home/build/src/main.c，那你要写set substitute-path /home/build /home/your/project - 如果原始路径是相对路径（比如
src/main.c），substitute-path无效，得用directory - 多个
substitute-path规则按添加顺序尝试，第一条匹配即停止，不会继续找
directory 命令的适用场景和限制
当符号表里存的是相对路径、或你明确知道所有源文件都在某几个固定目录下时，directory 是最直接的方式。它让 GDB 在这些目录里按文件名逐个查找，不依赖原始路径。
- 支持多个目录：
directory /path/a:/path/b:/path/c（Linux/macOS 用冒号分隔，Windows 用分号） - 路径必须存在且可读，否则 GDB 不报错但跳过该目录
- 它只影响后续的
list、break等命令，不影响已设置的断点位置——已有断点仍按原地址触发 - 常用技巧：把整个源码树根目录加进去，再配合
set filename-display basename让list显示更清爽
嵌入式/跨机编译时最容易漏掉的一环
交叉编译生成带调试信息的 ELF 后，GDB 默认**不会加载系统头文件或 libc 源码**，所以即使你的应用源码路径设对了，step 进 printf 或 malloc 时仍会卡在汇编。这不是路径问题，而是缺少目标平台的调试符号包（如 libc6-dbg 或 glibc-debuginfo）。
- 确认目标系统是否安装了调试符号：
dpkg -l | grep dbg（Debian/Ubuntu）或rpm -qa | grep debug（RHEL/CentOS） - 若无对应包，需手动下载并用
add-symbol-file加载，例如：add-symbol-file /path/to/libc.so.6.debug 0x7ffff7a0d000（地址需从info sharedlibrary查） - CLion 等 IDE 的远程调试配置里，“Symbol files” 字段填的不是路径列表，而是本地已解压的调试符号目录（如
/usr/arm-linux-gnueabihf/usr/lib/debug），GDB 会自动扫描子目录
