主要问题：
在Ubuntu尝试调试QNX中运行的嵌入式应用程序时，我从gdb收到以下错误消息：
warning: Shared object "$SOLIB_PATH/libc.so.4" could not be validated and will be ignored.，
问："；验证"；手术在进行吗
经过一些研究，我发现readelf -n libfoo.so报告的信息包含一个构建id，并将其与某些内容进行比较，可能存在不匹配，导致gdb拒绝加载库。如果是这种情况与共享对象的构建id相比，ELF文件的构建id是什么？我可以在解析可执行文件时找到这些信息吗
更多上下文：
我有一个.core文件用于此可执行文件。我使用的是QNX提供的gdb版本，并确保在安装QNX工具链的位置使用set sysroot和set solib-search-path。
我在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 path-to-exe.core path-to-executable-bin
Gdb抱怨无法加载共享对象：
warning: Shared object "$SOLIB_PATH/libc.so.4" could not be validated and will be ignored.
这里最重要的是确保您使用的二进制文件与目标文件(程序运行的二进制文件(完全相同。这对于libc来说通常是相当困难的，特别是因为libc/ldqnx有时是"；同样的事情"；它混淆了gdb。
最简单的方法是记录mkifs输出(在linux主机上(：
make 2>&1 | tee build-out.txt
然后通读一遍，搜索libc.so.4，并将被拉到目标上的二进制文件复制到中。(无论你在哪里运行gdb(，这样你就不需要麻烦SOLIB路径(懒惰的解决方案(。
或者，将一个新的libc(您想要使用的一个，理想情况下是您有关联符号的一个(scp/ftp到/tmp中，并使用LD_LIBRARY_PATH提取该libc(如果需要，还可以使用DL_DEBUG=libs进行确认(。使用相同的libc调试
来源：我在QNX工作，甚至我们有时也会遇到gdb+libc的问题