Re: Version mismatch libpthread/libthread_db

[Ryan Arnold <ryan dot arnold at gmail dot com>]

On Tue, Jul 7, 2009 at 5:32 AM, Martin Gebert<martin.gebert@alpha-bit.de> wrote:
> Hi all!
>
> I've been trying to build a crosscompiler toolchain including
> glibc-2.6.1 and thread support for a couple of days now. This seems to
> work for the most part, but when starting gdbserver on the target board
> and debugging a multithreaded application I get a warning about a
> version mismatch between libpthread and libthread_db; also the debugging
> seems to be broken in some cases (gdb cannot access memory at address
> 0x18 etc.). The best hint that I could find on the net regarding the
> cause were essentially saying "you must use both libraries from the same
> package", referring to binary packages of various Linux distributions;
> however both of these libs for my target where build in the same pass,
> and I made sure I deployed them to the board together.
> Digging into the code that causes this message, I found the version
> string comparison in nptl_db/td_ta_new.c:48, which reveals an empty
> string in versbuf that's being compared to "2.6.1". After I've tried
> several configuration variations and switches including
> "--enable-versioning" and with/without "--disable-debug" without
> success, I'm out of ideas now. Could anybody on this list please give me
> a hint what's going wrong?
> I'm building my cross-toolchain for mipsel-linux-gnu using a third party
> script provided by our BSP vendor, so I'm not 100% familiar with all the
> details of the toolchain building process; please bear with me. The
> configuration of the final, full-featured glibc build is started with
>
> $SRC_ROOT/glibc-2.6.1/configure --target=mipsel-linux-gnu
> --host=mipsel-linux-gnu --enable-add-ons=glibc-ports-2.6.1,nptl
> --enable-__cxa_atexit --without-cvs --disable-profile --without-gd
> --prefix= --without-fp --with-tls
>
> (environment variables replaced by the actual values used), with a lot
> more environment variables set from the previous GCC cross-build.
> Thanks for your help!

There are a few scenarios where this can happen.  I believe in the
case of remote debugging you need to make sure that the target
libraries on the remote system to be debugged exactly match the
cross-target libraries on the local system.

In native environments I have this problem when I'm trying to debug a
GLIBC from it's build directory, i.e. not installed.  GDB makes an
assumption that the thread_db is located relative to the prefix
directory where GDB is executed and not in the ${GLIBC}/nptl_db
directory and obviously what GDB generally finds in this prefix is a
different libthread_db version than what I'm debugging with a new
glibc.

This is a terrible assumption and as a result the following GDB patch
set was introduced and this problem was fixed in cvs HEAD.

http://sourceware.org/ml/gdb-cvs/2009-05/msg00091.html

As a work around I've used the new Glibc's loader to invoke gdb
because this sets the relative prefix directory for GDB correctly.  In
a cross environment you'd have to have a native (to the local machine)
GLIBC built so you could use it's loader to invoke the cross-GDB, and
this doesn't seem like a good work around in that case.

Ryan S. Arnold