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

["Jason Machacek" <jmachacek@stratos.com>]

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