GDB 执行报异常问题解决方案

GDB 执行报异常问题解决方案

摘要

本文详细分析了 GDB 执行报异常 “Can’t open file” 的原因，解释了其对调试的影响，并提供了一套完整的解决方案，包括获取目标板的库文件、设置 GDB 的搜索路径等，帮助开发者在调试过程中解决因缺少目标板运行时库文件而导致的调试受限问题。

问题描述

在使用 GDB 进行调试时，出现以下报异常信息：

warning: Can't open file /usr/lib/libupkcs11.so during file-backed mapping note processing
warning: Can't open file /usr/lib/librtlsdk.so during file-backed mapping note processing
warning: Can't open file /usr/lib/librsaverify.so during file-backed mapping note processing
warning: Can't open file /usr/lib/libxml2.so.2.12.7 during file-backed mapping note processing
warning: Can't open file /usr/lib/librtlswitch.so during file-backed mapping note processing
warning: Can't open file /usr/lib/libinstaller.so during file-backed mapping note processing

原因分析

1. 路径差异 ：程序是在目标设备（如 ARM 开发板）上崩溃的，运行时加载了位于目标设备绝对路径下的共享库文件。而当前调试环境是在 x86_64 主机（可能是 Windows 下的 WSL）上进行交叉调试G，DB 按 core 文件记录的绝对路径在调试主机上寻找相同的库文件时，这些路径在主机 / WSL 环境中不存在。
2. 调试环境差异 ：调试主机与目标设备的系统架构和文件系统结构不同，导致 GDB 无法直接找到目标设备上的共享库文件。

影响说明

• 可以分析可执行文件自身代码导致的崩溃。
• 无法查看涉及缺失库的堆栈帧信息、打印或查看这些库中定义的全局变量或结构体、在这些库的代码中设置断点以及查看涉及这些库代码的详细崩溃原因。

解决方案

1. 获取目标板的库文件 ：从目标板上复制可执行文件和所有警告中列出的库文件到调试主机的一个目录中，并按目标板路径结构放置文件。
2. 设置 GDB 的搜索路径 ：启动 GDB 并加载 core dump 后，使用 set sysroot 或 set solib-absolute-prefix 命令告诉 GDB 去哪里找目标板的库文件。也可以使用 set solib-search-path 指定库搜索路径。
3. ( 可选 ) 使用 symbol-file 加载带符号的可执行文件 ：如果主机上的可执行文件没有调试符号，而目标板上的可执行文件是带调试符号的版本，可在 GDB 中加载 core 之后，用 symbol-file 命令显式加载这个带符号的文件。

调试操作

确保路径正确后，重新加载 core 文件（或重启 GDB），GDB 应该不会再输出那些 “Can’t open file” 警告，此时可看到完整的堆栈信息，并能更有效地分析崩溃原因。