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] |
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] |