Remote Debugging multi-threaded C program with GDB

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, 开发者_如何学GoI still get the termination errors.

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

Thanks!

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.