ltrace: Nie można znaleźć .dynsym lub .dynstr w "library.so"

Question

Próbowałem użyć ltrace. Próbowałem użyć następującego polecenia, aby profilować plik library.so, który jest używany przez program sampleapp, ltrace -c -T --library=library.so --output=out.txt ./SampleApp. Ale pokazuje powyższy błąd. Ale biblioteka.so jest kompilacją debugowania. Więc tablica symboli powinna tam być. Próbowałem zweryfikować to przy pomocy objdump --source library.so | grep CreateSocket(). Zwraca kody, które używają tej funkcji CreateSocket(). Co oznacza, że ​​zawiera tablicę symboli. Dlaczego pojawił się ten błąd?

Related Post: measure CPU usage per second of a dynamically linked library

Answer 1

To zależy od tego, jak plik wykonywalny SampleApp został stworzony. Ten błąd zostanie wyświetlony, jeśli był statycznie połączony. ltrace działa tylko dla dynamicznie powiązanych aplikacji.

Można uruchomić ldd SampleApp, aby wyświetlić zależności obiektów współdzielonych. Jest dynamicznie powiązane i ma zależność do libc, wyjście ldd będzie zawierać linię:

libc.so.6 => /usr/lib/libc.so.6 (0x00007fb24ac53000) 

W takim przypadku można skorzystać z opcji ltrace --library=libc.so.6 i powinno działać. Jednak --library=libc.so nie będzie się zgadzać (nie dostaniesz błędu, ale żadne połączenie biblioteki nie zostanie dopasowane).

Kiedy statycznie powiązane, ldd SampleApp będzie zamiast pokazać wyjście:

not a dynamic executable 

Zgaduję, że to z powodu łączenia statycznego mogą być błędne. Ważne jest jednak to, że jeśli plik ltrace pokazuje ten błąd, musisz uruchomić diagnostykę samego pliku wykonywalnego (pliku binarnego) i sposobu jego utworzenia (opcje łącznika), a nie biblioteki współużytkowanej.

Pytanie How does ltrace (library tracing tool) work? ma kilka dobrych referencji, aby lepiej zrozumieć wnętrze pliku ltrace.