Remote Debugging multi-threaded C program with GDB

Question

I am using Eclipse to develop and remotely debug some software for an ARM Processor. Unfortunately the software I am writing is multi-threaded and I am unable to debug it. If I place a break-point in the thread code, i get the following message:

Child terminated with signal = 5

Child terminated with signal = 0x5

GDBserver exiting

After doing quite a bit of Googling, I found a "solution" that proposed using this:

strip --strip-debug libpthread.so.0

Unfortunately, I still get the termination errors.

I would really appreciate your help in getting this figured out!

Thanks!

I am not sure if this has something to do with multi threading as usually debugging it with gdb usually works fine. How have you called the strip command. The cc1.exe and gcc.exe prefixes are strange. I would call as a normal command in a bash. — dmeister
@dmeister This is the site where I found the "solution" http://sourceware.org/bugzilla/show_bug.cgi?id=8963 The way I called it was by adding that in the other flags part of the C builder in eclipse cause the call to be: arm-none-linux-gnueabi-gcc.exe -O0 -g3 -Wall -c -fmessage-length=0 strip --strip-debug libpthread.so.0 — avivas
Can you try it as a separate call instead of adding it the the builder. Be aware that this might require root permissions as it changes a system file (lbpthread.so.0). — dmeister
@dmeister I added it strip --strip-debug libpthread.so.0 as a post-build call but I keepy getting the same error message of Child terminated with signal = 5 — avivas
I also tried adding it to the .gdbinit and that didn't work either. I did find this extra error however: gdb: error initializing thread_db library — avivas

Employed Russian Employed Russian · Accepted Answer · 2011-06-10T20:33:44

First, this (and subsequent) error(s):

cc1.exe: error: unrecognized command line option "-fstrip-debug"

is caused by adding strip --strip-debug etc. to the GCC command line. That is obviously bogus thing to do, and not at all what your googling suggested. (You might want to clean up your question to remove references to these errors; they have nothing to do with your problem.)

What it did (or should have) suggested, is using strip --strip-debug libpthread.so.0 instead of using strip libpthread.so.0.

This is because GDB can not work with threads if your libpthread.so.0 is fully stripped.

It can be stripped of debug symbols (which is what strip --strip-debug libpthread.so.0 does), but stripping it of all symbols (which is what strip libpthread.so.0 does) is a bad idea(TM).

Since you are (apparently) not yourself building libpthread.so.0, you shouldn't need to strip it either.

You should however verify that the provider of your toolchain did not screw it up. The following command should not report no symbols, and should in fact print a matching nptl_version (as a defined symbol):

nm /path/to/target/libpthread.so.0 | grep nptl_version

Assuming all is well so far, we can now diagnose your problem, except ... you didn't provide sufficient info ;-( In particular, when you run GDB, it should print something like using /path/to/libthread_db.so.0. You might have to hunt for GDB console in Eclipse, or you might want to run GDB from command line, so you see exactly what it prints.

It is crucial that the version of libthread_db.so.0 (for host) matches the version of lipthread.so.0 (for target). They should both be provided by your toolchain vendor.

Your problem is most likely that either GDB can't find libthread_db.so.0 at all, or that it finds the wrong one.

Remote Debugging multi-threaded C program with GDB

1 Answers