Czego potrzebuję do debugowania pthreadów?

Question

Chcę debugować pthreads w mojej niestandardowej dystrybucji Linuksa, ale brakuje mi czegoś. Moim hostem jest Ubuntu 12.04, moim celem jest niestandardowy wbudowany Linux i486 zbudowany z zestawem narzędzi krzyżowych crosstool-NG, reszta systemu operacyjnego jest wykonana z Buildroot.

będę notować fakty:

• mogę uruchomić wielowątkowych aplikacji na moim celem

• Google Breakpad nie utworzyć raport awarii kiedy uruchomić wielowątkowych aplikacji na tarczy . Dokładnie ta sama aplikacja z dokładnie taką samą wersją bibliotek Breakpad zakończy się pomyślnie, gdy uruchomię go na moim hoście.

• GDB nie może debugować aplikacji wielowątkowych na moim celu.

np.

$./gdb -n -ex "thread apply all backtrace" ./a.out --pid 716 

dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_lgetfpregs 
GDB will not be able to debug pthreads. 
GNU gdb 6.8 

Nie sądzę ps_lgetfpregs jest problem, ponieważ od this.

• Moja kompilacja crosstool utworzyła plik libthread_db.so i umieściłem go na celu.

• Moja kompilacja crosstool utworzyła gdb dla mojego celu, więc powinna być połączona z tymi samymi bibliotekami, które uruchamiam na celu.

• Jeśli uruchomię gdb na moim hoście, w stosunku do mojej aplikacji testowej, otrzymam ślad każdego uruchomionego wątku.

Podejrzewam, że problem z urządzeniem Breakpad jest związany z problemem z GDB, ale nie mogę tego uzasadnić. Jedyną cechą wspólną jest brak debugowania wielowątkowego.

Istnieje pewna zasadnicza różnica między hostem a obiektem docelowym, która uniemożliwia mi debugowanie elementów Pthreads w celu.

Czy ktoś wie, co to jest?

EDIT:

Denys Dmytriyenko z TI mówi:

Normalnie GDB nie jest bardzo wybredna i można łączyć i dopasowywać różne wersje gdb i gdbserver. Ale, niestety, jeśli trzeba debugowania wielowątkowych aplikacjach, istnieją pewne zależności dla poszczególnych API ...

Na przykład, jest to jeden z tych komunikatów może pojawić się, jeśli nie build GDB odpowiednio za wsparcie wątku:

dlopen nie powiodła się 'libthread_db.so.1' - /lib/libthread_db.so.1: niezdefiniowany symbol: ps_lgetfpregs GDB nie będzie w stanie debugować pthreads.

Zauważ, że ten błąd jest taki sam jak ten, który dostaję, ale nie podchodzi do szczegółów, jak poprawnie zbudować GDB.

i GDB FAQ mówi:

(P) GDB nie widzi wątki oprócz tego, w którym nastąpiła awaria; lub SIGTRAP zabija mój program po ustawieniu punktu przerwania.

(A) To często dzieje się w systemie Linux, zwłaszcza w osadzonych obiektach docelowych. Istnieją dwie przyczyny: wspólne

• używasz glibc i zostały pozbawione libpthread.so.0

• niedopasowanie pomiędzy libpthread.so.0 i libthread_db.so.1

Sam GDB robi nie wie, jak rozszyfrować "bloki sterowania wątkami" utrzymywane przez glibc i uważane za szczegóły implementacji prywatnych glibc. Używa ona libthread_db.so.1 (część glibc), aby to ułatwić. Dlatego libthread_db.so.1 i libpthread.so.0 muszą pasować do flag kompilacji wersji i . Ponadto libthread_db.so.1 wymaga obecności pewnych nieglobalnych symboli w libpthread.so.0 w postaci .

Rozwiązanie: użyj paska --strip-debug libpthread.so.0 zamiast paska libpthread.so.0.

Próbowałem nieodczytanego libpthread.so.0, ale nie miało to znaczenia. Zbadam wszelkie niedopasowania między pthread i thread_db.

Answer 1

to:

dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_lgetfpregs 
GDB will not be able to debug pthreads. 

oznacza, że ​​biblioteka libthread_db.so.1 nie był w stanie znaleźć symbol ps_lgetfpregs w gdb.

Dlaczego?

Ponieważ zbudowałem gdb za pomocą Crosstoolg-NG z opcją "Zbuduj statyczny macierzysty gdb", a to dodaje opcję gcc do -static.

Natywny gdb jest zbudowany z opcją -rdynamic i wypełnia tabelę symboli .dynsym w pliku ELF ze wszystkimi symbolami, nawet nieużywanymi. libread_db używa tej tabeli symboli, aby znaleźć ps_lgetfpregs z gdb.

Ale -static pobiera z tabeli ELF tabelę .dynsym.

W tym momencie dostępne są dwie opcje:

1. nie budują statyczny natywną gdb jeśli chcesz debugować wątki.
2. zbudować statycznych gdb i statyczny libthread_db (nie testowane)

Edit:

nawiasem mówiąc, to nie wyjaśnia, dlaczego Breakpad w stanie do debugowania wielowątkowych aplikacji na moim celem.

Answer 2

Po prostu ... Aby użyć debuggera gdb, musisz skompilować swój kod za pomocą opcji -g. Na przykład gcc -g -c * .c.