Cross-platform, multithreaded debugging (x86 to ARM) with gdb and gdbserver not recognizing threads

Jason Machacek jmachacek@stratos.com
Thu Dec 17 18:01:00 GMT 2009


Hi Paul,

Thanks for the reply.


> A couple of questions:
> - Does gdbserver config.log mention libthread_db.so, and if so, which
one?

$ cat config.log | grep libthread_db -A8
configure:3888: checking for libthread_db
configure:3919:
/opt/crosstool/gcc-3.4.4-glibc-2.3.2/arm-linux/bin/arm-linux-gcc -o
conftest -g -O2   conftest.c  -lthread_db >&5
configure:3925: $? = 0
configure:3929: test -z 
			 || test ! -s conftest.err
configure:3932: $? = 0
configure:3935: test -s conftest
configure:3938: $? = 0
configure:4014: result: -lthread_db

It appears gdbserver with the correct libthread_db--my toolchain is
mentioned, so I'm assuming it's linking the correct library.  It's the
only ARM-compatible libthread_db.so on my system. 



> - Does ldd gdbserver on target show libthread_db.so, and if so, is the
> right one? (Should come from the same compilation from which libc.so.6
> and libpthread.so.0 came.)

I unfortunately don't have ldd on my target, but gdbserver's maps file
shows that it's grabbing libthread_db.so.  I installed that version of
libthread_db.so myself from the toolchain along with libpthread.so, and
libc.so.6 is statically linked into my application.

$ cat /proc/212/maps 
00008000-00016000 r-xp 00000000 1f:01 549        /root/gdbserver
0001e000-0001f000 rw-p 0000e000 1f:01 549        /root/gdbserver
0001f000-00042000 rwxp 00000000 00:00 0 
2aaab000-2aac0000 r-xp 00000000 1f:01 607        /lib/ld-2.3.2.so
2aac0000-2aac1000 rw-p 00000000 00:00 0 
2aac7000-2aac8000 rw-p 00014000 1f:01 607        /lib/ld-2.3.2.so
2aac8000-2aacc000 r-xp 00000000 1f:01 799
/lib/libthread_db-1.0.so
2aacc000-2aad0000 ---p 00004000 1f:01 799
/lib/libthread_db-1.0.so
2aad0000-2aad4000 rw-p 00000000 1f:01 799
/lib/libthread_db-1.0.so
2aad4000-2abec000 r-xp 00000000 1f:01 687        /lib/libc-2.3.2.so
2abec000-2abf6000 rw-p 00110000 1f:01 687        /lib/libc-2.3.2.so
2abf6000-2abf9000 rw-p 00000000 00:00 0 
7fffd000-80000000 rwxp ffffe000 00:00 0



> - Is libpthread.so.0 on target stripped?

It doesn't appear to be.  I made a copy of libthread_db-1.0.so and ran
'strip' on it, and the file size dropped.  Is this the correct approach?

$ cp
/opt/crosstool/gcc-3.4.4-glibc-2.3.2/arm-linux/arm-linux/lib/libthread_d
b-1.0.so .
$ ls -l libthread_db-1.0.so 
-rwxr-xr-x 1 jason jason 29579 2009-12-17 09:49 libthread_db-1.0.so
$ /opt/crosstool/gcc-3.4.4-glibc-2.3.2/arm-linux/bin/arm-linux-strip
libthread_db-1.0.so 
$ ls -l libthread_db-1.0.so 
-rwxr-xr-x 1 jason jason 18296 2009-12-17 09:50 libthread_db-1.0.so

I tried just stripping debugging information as well, and that also
decreased the file size:

$ ls -l libthread_db-1.0.so 
-rwxr-xr-x 1 jason jason 29579 2009-12-17 09:53 libthread_db-1.0.so
$ /opt/crosstool/gcc-3.4.4-glibc-2.3.2/arm-linux/bin/arm-linux-strip
--strip-debug libthread_db-1.0.so 
$ ls -l libthread_db-1.0.so
-rwxr-xr-x 1 jason jason 23781 2009-12-17 09:54 libthread_db-1.0.so


Does this indicate that I've got a library version mismatch somewhere in
my system?  I'm using a toolchain from my SBC supplier, but perhaps that
wasn't the toolchain they used to build all the libraries included on
the target.

Is there any problem with setting up a second set of libraries on my
system?  E.g. /lib2 that contains the libraries copied from my
toolchain.  Would I have to make changes to my toolchain's directory
structure to ensure the directories matched up with those on the target
(for GDB that is)?


Thanks,
Jason



More information about the Gdb mailing list