GDB启动后info sharedlibrary为空，主因是core中记录的so路径在本地不匹配；应优先用set solib-search-path指定本地so目录，或set sysroot指向目标根文件系统，再执行info sharedlibrary验证加载状态。
gdb 启动后看不到动态库信息，先确认是否加载成功
直接运行 gdb ./a.out core 后，info sharedlibrary 显示为空或只有部分库，不是 GDB 崩了，而是它根本没找到对应 so 文件。GDB 不会自动从系统路径（如 /lib64 或 $LD_LIBRARY_PATH）去搜——尤其当 core 是在另一台机器、另一个环境生成的，路径几乎必然不匹配。
用 set solib-search-path 指定本地 so 存放目录
这是最常用也最可靠的方案，适用于你已把所有依赖的 .so 文件（包括 libc、libstdc++ 和业务自研库）统一拷贝到某个本地目录（比如 /path/to/libs）的场景：
-
set solib-search-path /path/to/libs:/path/to/libs/deps—— 多路径用冒号隔开，GDB 会按顺序尝试拼接 - 执行后立刻运行
info sharedlibrary，正常应列出所有库及其状态（Yes表示已加载符号，No表示只映射未读符号） - 若仍显示
No，说明该 so 缺调试信息（没带.debug段或没编译-g），此时bt可能只显示 ??:?，但地址和调用关系仍在
set sysroot 适合完整复制目标系统根目录的场景
当你有目标机器的完整文件系统快照（例如容器 rootfs 或嵌入式 SDK 的 sysroot），且 so 路径是绝对路径（如 /usr/lib/libxxx.so）时，set sysroot 更自然：
-
set sysroot /path/to/target-rootfs—— GDB 会把所有绝对路径的 so 当作相对于该目录查找 - 注意：
set sysroot和set solib-absolute-prefix是同一个命令，别重复设置 - 如果 core 里混用了绝对路径和相对路径（比如 dlopen("./plugin.so")），单靠
sysroot不够，必须配合solib-search-path
检查动态库实际加载路径和缺失项
崩溃现场的 so 路径记录在 core 文件里，GDB 加载时会打印提示。关键要看启动后 GDB 的输出：
- 如果看到类似
warning: Could not load shared library symbols for 2 libraries, e.g. /lib/x86_64-linux-gnu/libc.so.6.，就说明这些路径在本地不存在 - 用
info proc mappings查看进程内存中 so 的原始加载地址和路径（即使没符号也能看到） - 用
readelf -d ./a.out | grep NEEDED确认程序声明依赖哪些库名，再比对info sharedlibrary输出，缺哪个就补哪个
真正容易被忽略的是：core 文件里保存的是崩溃时刻的 so 路径，不是编译时的路径；而 GDB 默认只信任这个路径。哪怕你本地有同名 so，只要路径不对，它就不会加载——必须用 solib-search-path 或 sysroot 主动告诉它“去哪找”。
