为什么gdb拒绝加载我的共享对象？验证操作是什么 主要问题:

在Ubuntu试图调试QNX中运行的嵌入式应用程序时，我从gdb收到以下错误消息：

警告：无法验证共享对象“$SOLIB_PATH/libc.so.4”，将被忽略。

Q：“验证”操作在进行什么？

经过一些研究后，我发现，

readelf-nlibfoo.so

报告的信息包含一个构建id，这与某些内容进行了比较，可能存在不匹配，导致gdb拒绝加载库。如果是这种情况，与共享对象的构建id相比，ELF文件的构建id是什么？我可以在解析可执行文件时找到此信息吗？

更多背景： 我有这个可执行文件的.core文件。我正在使用QNX提供的gdb版本，并确保使用

set sysroot

和

set solib search path

安装QNX工具链的位置

我在Ubuntu中启动gdb的完整命令是：

$QNX_工具链_路径/ntox86_64-gdb--init eval命令'set sysroot$sysroot_路径'--init eval命令'set solib搜索路径$solib_路径--init eval命令'python sys.PATH.append（“/usr/share/gcc-8/python”）；'-c path-to-exe.core可执行文件箱路径

Gdb抱怨无法加载共享对象：

---

警告：共享对象“$SOLIB_PATH/libc.so.4”无法验证，将被忽略。

这里最重要的一点是确保您使用的是目标上的完全相同的二进制文件（该程序在其上运行）。对于libc来说，这通常是相当困难的，特别是因为libc/ldqnx有时是“同一件事”，并且会混淆gdb

最简单的方法是记录mkifs输出（在linux主机上）：

通读一遍，搜索libc.so.4，然后将目标上的二进制文件复制到。（无论您在哪里运行gdb）这样您就不需要弄乱SOLIB路径（惰性解决方案）

或者，scp/ftp将一个新的libc（一个您想要使用的libc，最好是一个您有相关符号的libc）放入/tmp中，并使用LD_LIBRARY_PATH拉取该libc（如果需要，DL_DEBUG=libs进行确认）。使用相同的libc进行调试

资料来源：我在QNX工作，甚至我们有时也会与gdb+libc打交道

make 2>&1 | tee build-out.txt