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]

Re: debugging pthreads


On 7 September 2012 13:26, Bill Pringlemeir <bpringle@sympatico.ca> wrote:
> On  7 Sep 2012, aras.vaichas@gmail.com wrote:
>
>> 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.
>
> It seems that you need symbols to debug threads.  I guess that gdb is
> looking for variables to determine what threads/stacks are where.  It
> cann't seem to get back traces without symbols in the 'libc', etc.
>
> Have you stripped everything before you put it on your target?

Nope. Libraries are used as-is from Crosstools and Buildroot. The only
build difference between my test app build for host and target is the
C++ compiler. Yet GDB works on my host, but does not work on my target
for multithreaded apps. GDB does work for single threaded apps on my
target.

I found some interesting leads. Denys Dmytriyenko from TI said:

"Normally, GDB is not very picky and you can mix and match different
versions of gdb and gdbserver. But, unfortunately, if you need to
debug multi-threaded apps, there are some dependencies for specific
APIs...
For example, this is one of the messages you may see if you didn't
build GDB properly for the thread support:
dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1:
undefined symbol: ps_lgetfpregs
GDB will not be able to debug pthreads."

ref: http://e2e.ti.com/support/embedded/linux/f/354/t/52720.aspx

This is the same error message that I get.

The GDB FAQ says a cause of problems with GDB and threads can be:

"[a] mismatch between libpthread.so.0 and libthread_db.so.1
GDB itself does not know how to decode "thread control blocks"
maintained by glibc and considered to be glibc private implementation
detail. It uses libthread_db.so.1 (part of glibc) to help it do so.
Therefore, libthread_db.so.1 and libpthread.so.0 must match in version
and compilation flags. In addition, libthread_db.so.1 requires certain
non-global symbols to be present in libpthread.so.0. Solution: use
strip --strip-debug libpthread.so.0 instead of strip libpthread.so.0."

ref: http://sourceware.org/gdb/wiki/FAQ


> ...probably not a CTNG issue.

GDB, libpthread and libthread_db are all configured and built by
crosstools, so it seems the most likely place to look for the answers.

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]