CODEWITHSUNDEEP
linuxgdb
Ken Lin
Ken Lin

Reputation: 1035

Error while loading libthread_db for cross-platform gdb-multiarch debugging

I have a host machine running 64-bit Linux in x86, and a target board running 32-bit Linux in ARM. I am using gdb-multiarch on the host machine to debug core dump files generated from a multi-threaded binary running on the target board. The debugging seems to work (at least the basic things such as bt, info threads, etc).

However, I see warnings related to libthread_db on startup. I learned that you can use set debug libthread-db 1 to get some extra debug message, and this is what I observed:

  1. First, I see the libthread_db from the host machine is being loaded. This fails due to a version mismatch but that seems completely reasonable in my opinion. After all, why would the libpthread from my target board be compatible with the libthread_db on my host machine?
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. Then, I see the libthread_db from the target board is being loaded (I have the ARM shared libraries on my host machine). It appears that it failed because dlopen is expecting a 64-bit shared library, but this doesn't make sense to me because the core dump is generated from a 32-bit binary.
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. Finally, gdb-multiarch complains that thread debugging isn't available.
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

What am I doing wrong that's preventing libthread_db from being loaded properly?

Upvotes: 1

Views: 1346

Answers (1)

Employed Russian
Employed Russian

Reputation: 213375

What am I doing wrong that's preventing libthread_db from being loaded properly?

You aren't doing anything wrong, but you need to have an x86_64 version of libthread_db.so.1 which is the same version as GLIBC on your 32-bit ARM target.

Alternatively you could use 32-bit GDB on the host. That GDB would be able to dlopen <snipped path>/lib/libthread_db.so.1. Since your target is 32-bit, you are not gaining anything by using 64-bit GDB on the host.

Update:

exactly what gdb is using libthread_db.so.1 for?

GDB does not know about internals of libpthread.so.0, so it dynamically loads libthread_db.so.1 and asks it to e.g. enumerate threads and tell GDB about them.

Obviously for this dynamic loading (dlopen) to work, libthread_db.so.1 must match GDB bitness and architecture. But in order for libthread_db to know about internals of libpthread.so.0, it must version-match libpthread.so.0 used by the target.

You might ask: how can libthread_db enumerate threads in the target process? Doesn't it need to know memory contents of the inferior (being debugged) process?

Why yes, it does, and it uses GDB to perform inferior reads and writes.

That is, GDB calls into libthread_db, which calls back into GDB for low-level inferior memory and register access, then uses the info provided by GDB to construct higher-level concepts (active threads, etc.).

Upvotes: 1

Related Questions