This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See crosstool-NG for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

debugging pthreads


Hello,

I am having trouble debugging pthreads on my target. I am not sure
what the cause is, but I suspect it could be either my kernel or my
libraries.

I am using crosstool-ng-1.16.0 to create tools for for an
i486-linux-unknown-gnu target, gcc 4.4.6, glibc 2.9, kernel 3.3.8.

I have created the target gdb and gdbserver using ctng.

I can run multithreaded apps on my target, but I cannot debug them
with gdb or Google Breakpad.

e.g. gdb simply fails

--- snip ---
$ ./gdb --batch -n -ex "thread apply all backtrace" ./a.out --pid 716

dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1:
undefined symbol: ps_lgetfpregs
GDB will not be able to debug pthreads.

0xb75aa78c in nanosleep () from /lib/libc.so.6

<< there should be backtraces for several threads here>>
--- snip ---


I understand the "undefined symbol" shouldn't be a problem because of
this: http://permalink.gmane.org/gmane.linux.debian.devel.glibc/4409

If I run the same app on my host, I get backtraces for all the threads.

e.g. gdb on my host with the same test application:

--- snip ---
sudo gdb --batch -n -ex "thread apply all backtrace" ./a.out --pid 17806
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb53ffb40 (LWP 17811)]
[New Thread 0xb5f42b40 (LWP 17810)]
[New Thread 0xb6743b40 (LWP 17809)]
[New Thread 0xb6f44b40 (LWP 17808)]
[New Thread 0xb7745b40 (LWP 17807)]
0x00bec416 in __kernel_vsyscall ()
Thread 6 (Thread 0xb7745b40 (LWP 17807)):
#0  0x00bec416 in __kernel_vsyscall ()
#1  0x0074ec16 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2  0x0074ea0f in sleep () from /lib/i386-linux-gnu/libc.so.6
#3  0x0804a3b2 in thread () at test.cpp:8
#4  0x0804b919 in boost::detail::thread_data<void (*)()>::run
(this=0x8a22008) at /usr/include/boost/thread/detail/thread.hpp:61
#5  0x0096f1cc in ?? () from /usr/lib/libboost_thread.so.1.48.0
#6  0x00134d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#7  0x00785ace in clone () from /lib/i386-linux-gnu/libc.so.6

... etc...

Thread 1 (Thread 0xb7747700 (LWP 17806)):
#0  0x00bec416 in __kernel_vsyscall ()
#1  0x0074ec16 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2  0x0074ea0f in sleep () from /lib/i386-linux-gnu/libc.so.6
#3  0x0804a3d2 in f4 () at test.cpp:14
#4  0x0804a3eb in f3 () at test.cpp:20
#5  0x0804a3f8 in f2 () at test.cpp:25
#6  0x0804a405 in f1 () at test.cpp:30
#7  0x0804a4a2 in main () at test.cpp:41
--- snip ---

Google Breakpad simply fails to product a minidump for any application
that contains threads. It does not fail on my target when the test app
is single threaded. The same Google Breakpad library works on my host
with a multi threaded test application.

Is there something fundamental that needs to be in place for pthread
debugging that I may have omitted from my build or system?

Does libthread_db have any other dependencies?

Aras

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]