使用共享库.so的可执行程序coredump栈回溯无函数名问题咨询

关联了.so的可执行程序完全可以正常解析coredump调用栈，看不到.so内部函数名通常是调试信息缺失、符号未正确加载导致的，具体可参考以下方案：

可用栈回溯方案 #

• 优先确认gdb符号加载状态：执行gdb ./你的可执行程序 ./core文件启动调试后，先运行info sharedlibrary命令查看对应.so的Syms Read列是否为Yes。如果为No，执行set solib-search-path 你的.so存放目录指定搜索路径后即可加载符号。
• 用elfutils工具快速解析：安装elfutils包后，直接执行eu-stack --core=./core文件 ./你的可执行程序即可自动匹配关联的.so，输出完整调用栈，无需手动配置符号路径，适合快速排查场景。
• 离线符号匹配解析：如果生产环境部署的.so已经做过strip裁剪，只要留存构建环节生成的未strip的.so副本，解析时把副本放到指定路径，即可正常匹配地址解析符号，无需修改生产环境二进制。
• 帧指针强制保留：如果是编译器优化（-O2及以上优化等级默认会省略帧指针）导致的栈回溯失败，给.so的编译参数添加-fno-omit-frame-pointer即可，哪怕没有调试信息也能正常完成栈回溯。

建议调整的构建流程 #

• 共享库和主程序编译时都要添加-g参数生成调试信息：-g参数不会影响运行时性能，仅会增加二进制体积，生产环境可以单独抽离调试信息，无需直接部署带调试信息的二进制。
• 增加调试信息分离步骤：不要直接strip构建产物，执行objcopy --only-keep-debug ./libxxx.so ./libxxx.so.debug将调试信息单独保存为符号文件，再执行strip ./libxxx.so生成生产环境用的裁剪版本，排查问题时gdb会自动关联对应符号文件。
• 统一主程序和共享库的编译规则：如果当前构建流程仅给主程序加了-g参数，必须同步给所有共享库加上，共享库的调试信息是独立存储的，主程序的调试信息不包含.so内部的符号表。

常见注意事项 #

• 解析coredump时使用的.so版本必须和生成coredump时运行的版本完全一致，哪怕代码只有微小差异，也会导致地址偏移不匹配，无法正常解析符号。
• 不需要在生产环境部署带调试信息的二进制，只要留存构建环节产出的未strip副本即可满足离线解析需求。

内容的提问来源于stack exchange，提问作者Rajamanickam Srinivasan