主要问题:
在 Ubuntu 中尝试调试在 QNX 中运行的嵌入式应用程序时，我从 gdb 收到以下错误消息:
警告:共享对象“$SOLIB_PATH/libc.so.4”无法验证，将被忽略。,
问:正在进行什么“验证”操作？
经过一番研究，我发现 readelf -n libfoo.so 报告的信息包含一个 build-id，并且将其与某些内容进行比较，并且可能存在不匹配导致 gdb 拒绝加载图书馆。如果是这种情况，与共享对象的 build-id 相比，ELF 文件的 build-id 是什么？我可以在解析可执行文件时找到此信息吗？
更多上下文:
我有一个用于此可执行文件的.core 文件。我正在使用 QNX 提供的 gdb 版本，并确保将 set sysroot 和 set solib-search-path 用于安装 QNX 工具链的位置。
我在 Ubuntu 中启动 gdb 的完整命令是:
$QNX_TOOLCHAIN_PATH/ntox86_64-gdb --init-eval-command 'set sysroot $SYSROOT_PATH' --init-eval-command 'set solib-search-path $SOLIB_PATH --init-eval-command 'python sys.path.append(“/usr/share/gcc-8/python”);' -c exe 路径.core 可执行文件路径
Gdb 提示它无法加载共享对象:
警告:共享对象“$SOLIB_PATH/libc.so.4”无法验证，将被忽略。
最佳答案
这里最重要的是确保您使用与目标(程序运行的)上完全相同的二进制文件。对于 libc，这通常相当困难，特别是因为 libc/ldqnx 有时是“同一件事”并且它使 gdb 感到困惑。
最简单的方法是记录 mkifs 输出(在 Linux 主机上):
make 2>&1 | tee build-out.txt
通读一遍，搜索 libc.so.4，然后将拉入目标的二进制文件复制到 . (无论你在哪里运行 gdb)，这样你就不需要弄乱 SOLIB 路径(懒惰的解决方案)。
或者，通过 scp/ftp 将一个新的 libc(您想要使用的一个，最好是您有关联符号的一个)复制到/tmp 中，并使用 LD_LIBRARY_PATH 来提取该 libc(如果需要，请使用 DL_DEBUG=libs 进行确认) )。使用相同的 libc 进行调试
来源:我在 QNX 工作，甚至我们有时也很难使用 gdb + libc
关于gdb - 为什么 gdb 拒绝加载我的共享对象以及验证操作是什么，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/64072247/