Во-первых, эта (и последующие) ошибка (и):
cc1.exe: error: unrecognized command line option "-fstrip-debug"
вызвано добавлением strip --strip-debug и т. Д. В командную строку GCC. Это очевидно фиктивная вещь, которую нужно сделать, а вовсе не то, что предложил ваш поиск в Google. (Возможно, вы захотите очистить свой вопрос, чтобы удалить ссылки на эти ошибки; они не имеют никакого отношения к вашей проблеме.)
То, что он сделал (или должен был) предложить, использует strip --strip-debug libpthread.so.0 вместо использования strip libpthread.so.0.
Это потому, что GDB не может работать с потоками , если ваш libpthread.so.0 полностью удален.
Его можно удалить из символов отладки (что делает strip --strip-debug libpthread.so.0), но удаление всех символов (что делает strip libpthread.so.0) - плохая идея (TM).
Поскольку вы (по-видимому) сами не строите libpthread.so.0, вам также не нужно снимать его.
Вы должны , однако убедитесь, что провайдер вашей цепочки инструментов не облажался. Следующая команда не должна сообщать no symbols, и на самом деле должна печатать соответствующий nptl_version (как определенный символ):
nm /path/to/target/libpthread.so.0 | grep nptl_version
Предполагая, что все хорошо, теперь мы можем диагностировать вашу проблему, за исключением ... вы не предоставили достаточно информации ;-( В частности, когда вы запускаете GDB, он должен напечатать что-то вроде using /path/to/libthread_db.so.0. Вы можете вам придется искать консоль GDB в Eclipse, или вы можете запустить GDB из командной строки, чтобы вы точно видели, что она печатает.
Крайне важно, чтобы версия libthread_db.so.0 (для хоста) соответствовала версии lipthread.so.0 (для цели). Они оба должны быть предоставлены вашим поставщиком инструментов.
Скорее всего, ваша проблема в том, что GDB вообще не может найти libthread_db.so.0 или что он находит неправильный.