debugging - GDB远程调试: influences on execution on remote target

Question

背景

我正在使用定制工具链(基于 Yocto 以及 gcc 4.7 和 gdb 7.5)使用 ARM 设备，并使用 Eclipse CDT 作为调试器前端进行远程 gdb 调试。最近，我遇到了一个问题，即我无法在远程目标上调试特定的可执行文件，因为当主机 gdb 连接到目标时立即发生此错误(由目标上的 gdbserver 报告):

error while loading shared libraries: unexpected PLT reloc type 0xf0

我终于可以通过调用 set sysroot 来追踪目标和主机上动态链接器库 /lib/ld-2.16.so 的二进制文件不匹配的问题 在 gdb 中，我使用了随工具链一起生成的本地存储的目标根目录。

保持本地文件与远程文件同步是可行的，但我也可以省略设置 sysroot 以便至少调试可执行文件本身。这导致我想到以下内容

问题

在调试主机上使用错误的 ld.so 二进制文件如何影响目标上 gdbserver 内应用程序的执行？如果主机上根本没有 ld.so ，我宁愿期望在主机上得到错误的调试信息，因为可执行文件在目标(在 gdbserver 内)上运行没有问题。但由于行为不同，当文件可用时，似乎有一些从主机到目标的反馈。

Answer 1

How does the usage of a wrong ld.so binary on the debugging host influence the execution of the application within gdbserver on the target?

好问题。

一种可能的解释:为了正确跟踪例如在目标上加载共享库时，GDB 设置了许多内部断点(这些断点在维护信息断点输出中可见 - 它们的断点编号为负)。

当您根本不提供本地文件时，GDB 不知道在哪里设置这些断点，因此它不会(例如，如果没有它们，您就无法调试库初始值设定项)。

当您提供不正确的本地文件时，GDB 会在错误的位置设置断点(通过覆盖 GDB 认为是指令的内容，但实际上是 PLT 重定位)。当加载器遇到这个被覆盖的重定位时，它会提示。