跨平台gdb多头调试加载libthread_db时出错

Question

我有一个在x86中运行64位Linux的主机，在ARM中有一个运行32位Linux的目标板。我使用主机上的gdb-multiarch来调试从目标板上运行的多线程二进制文件生成的核心转储文件。调试似乎是可行的(至少是基本的东西，如bt、info threads等)。

但是，我在启动时看到了与libthread_db相关的警告。我了解到您可以使用set debug libthread-db 1获得一些额外的调试消息，这就是我观察到的：

首先，我看到来自主机的

1. 正在加载。这是由于版本不匹配而失败的，但在我看来，这似乎是完全合理的。毕竟，为什么我的目标板上的libpthread与主机上的libthread_db兼容？

Trying host libthread_db library: libthread_db.so.1.
Host libthread_db.so.1 resolved to: /lib/x86_64-linux-gnu/libthread_db.so.1.
td_ta_new failed: versions of libpthread and libthread_db do not match

然后，我看到来自目标板的

1. 正在加载(我的主机上有ARM共享库)。它似乎失败了，因为binary.

需要64位共享库，但这对我来说没有意义，因为核心转储是从32位的生成的。

Trying host libthread_db library: <snipped path>/lib/libthread_db.so.1.
dlopen failed:  <snipped path>/lib/libthread_db.so.1: wrong ELF class: ELFCLASS32.
thread_db_load_search returning 0

1. 最后，gdb-multiarch抱怨线程调试不可用。

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

，我做错了什么，这妨碍了libthread_db的正确加载？

Answer 1

，我做错了什么，这妨碍了libthread_db的正确加载？

您没有做错什么，但是您需要在32位ARM目标上有一个与GLIBC相同的x86_64版本的libthread_db.so.1。

或者，您可以在主机上使用32位GDB。GDB将能够dlopen <snipped path>/lib/libthread_db.so.1。因为您的目标是32位，所以在主机上使用64位GDB不会获得任何信息。

更新：

，gdb到底是用来做什么的？

GDB不知道libpthread.so.0的内部结构，所以它动态地加载libthread_db.so.1并要求它例如枚举线程并告诉GDB关于它们的信息。

显然，要使这个动态加载(dlopen)工作，libthread_db.so.1必须与GDB比特性和体系结构匹配。但是为了让libthread_db了解libpthread.so.0的内部结构，它必须与目标使用的libpthread.so.0版本匹配。

您可能会问：libthread_db如何枚举目标进程中的线程？它不需要知道次进程(正在调试)的内存内容吗？

为什么要这样做呢?它使用GDB执行劣质的读写操作。

也就是说，GDB调用到libthread_db，后者调用GDB进行低级劣质内存和寄存器访问，然后使用GDB提供的信息构建更高级别的概念(活动线程等)。