“dso missing from command line”表示gdb加载core文件时无法找到程序依赖的动态库（如libmylib.so），根本原因是gdb未感知到库路径，而非库不存在；最直接解法是启动时用-ex "set solib-search-path "指定含.so文件的完整搜索路径，并注意包含系统默认路径、检查rpath/runpath及set auto-solib-add on。
gdb加载core时提示“DSO missing from command line”
这表示GDB在解析core文件时，发现程序运行依赖的某个动态库（如libmylib.so）没被找到，无法加载符号——不是程序跑不起来，而是你进不了调试现场。根本原因不是库不存在，而是GDB压根没“看见”它。
用set solib-search-path指定动态库搜索路径
最直接有效的办法是启动GDB时就告诉它去哪儿找库。注意：这个路径必须包含.so文件本身，不能只给到上层目录（除非该目录下还有子目录结构匹配RPATH）。
gdb -ex "set solib-search-path /usr/local/lib:/opt/myapp/libs" ./myapp core-12345- 如果路径含空格或特殊字符，用单引号包裹：
gdb -ex 'set solib-search-path "/path/with space"' ./myapp core - 多个路径用冒号分隔（Linux/macOS），Windows用分号；别漏掉系统默认路径如
/lib64或/usr/lib/x86_64-linux-gnu，否则libc.so.6这类基础库也可能报错
检查可执行文件的RPATH和RUNPATH是否生效
很多程序编译时加了-Wl,-rpath,/path/to/libs，但GDB默认忽略这些信息。你可以用readelf -d ./myapp | grep -E 'RPATH|RUNPATH'确认是否写入；若存在，需额外启用：
- 在GDB中执行：
set auto-solib-add on（默认就是on，但有时被关了） - 再手动触发加载：
sharedlibrary或sharedlibrary libmylib.so - 如果RPATH里是相对路径（如
$ORIGIN/../lib），GDB不会自动展开——得把./myapp放在它原本运行的目录下，或者用set cwd /original/work/dir模拟原始环境
core文件里记录的库路径可能已失效
core文件保存的是崩溃瞬间的内存映像，其中也存了当时加载的共享库绝对路径（可用readelf -n core-12345 | grep -A20 "NT_FILE"粗略查看）。如果机器迁移过、库被重装或路径被清理，那些路径就成死链了。
- 别依赖
info sharedlibrary输出的“Loaded”列表——它只反映当前GDB能加载的，不是core里记的原始路径 - 用
info proc mappings看core里实际映射的地址范围和文件名，再比对本地是否存在对应文件 - 最稳妥的做法：把崩溃机器上的
/proc/<pid>/maps</pid>（如果有保留）和ldd ./myapp结果一起带上，对照还原依赖树
真正麻烦的不是找不到库，而是GDB静默跳过缺失库、只在bt里显示??——这时候得先set debug solib 1打开加载日志，才能看清它到底去哪找了、为什么失败。
