Ponieważ ldd zawiera tylko biblioteki dynamiczne, czy istnieje sposób na wyodrębnienie informacji o statycznych bibliotekach używanych do tworzenia pliku wykonywalnego?Wyświetl listę bibliotek statycznych używanych w pliku wykonywalnym
ldd <exe filename> pokazuje dynamicznie powiązane biblioteki
nm <exe filename> przedstawia symbole w pliku.
Aby zobaczyć, które symbole pochodzą z bibliotek statycznych, należy uruchomić nm w tych bibliotekach, aby uzyskać listę symboli (funkcji itp.), A następnie porównać je z listą symboli z nm <exe filename>.
Porównuje się listy z poleceniem comm. Aby uzyskać szczegółowe informacje, patrz man comm.
To zostało zrobione z tego forum here.
Nie, nazwy bibliotek są odrzucane podczas procesu łączenia. Jeśli jednak plik wykonywalny zawiera informacje debugowania (tzn. Został skompilowany z flagą -g), może być możliwe uzyskanie z tego informacji.
Czy nie można rozpoznać ASA RAW, czy optymalizacja kompilatora i flagi również mają na to wpływ? – MrMesees
Chyba, że dany kompilator przechowuje jakieś dane meta wewnątrz pliku binarnego, wtedy nie. Biblioteka statyczna to kod, który jest bezpośrednio wkompilowany w plik binarny.
Jeśli masz kod źródłowy i nie chcesz przechodzić przez cały ten kod, możesz wygenerować plik mapy podczas kompilacji, aby wiedzieć, które statyczne biblioteki są połączone.
Na przykład g++ -Xlinker -Map=a.map main.c, sprawdź plik mapy dla połączonych informacji z biblioteki statycznej.
Nie ma sposobu, aby uzyskać listę bibliotek statycznych wewnątrz jakiegoś pliku wykonywalnego ELF.
Ponieważ dla łącznika, biblioteka statyczna jest właśnie używana jako "leniwy" zestaw elementów. Wynikowy plik wykonywalny ELF zawierałby tylko członków potrzebnych do połączenia. Zatem członkowie tacy jak foo2.o z libfoo.a są połączeni tak, jakby plik obiektów foo2.o został połączony z plikiem wykonywalnym (pod warunkiem, że potrzebny jest jakiś symbol zdefiniowany w foo2, tj. Jest gdzieś odwoływany).
Oczywiście, używając nm lub objdump lub readelf lub strings na jakiegoś pliku wykonywalnego ELF może dać pewne wskazówki na temat tego, co pliki wynikowe (w tym tych pochodzących z statycznych bibliotek) są w środku, bo zobaczysz symbole zdefiniowane w (elementach) tych statycznych bibliotek (lub literalnych łańcuchach używanych w nich).
jakie wskazówki masz na myśli? Czy możesz podać przykłady? Czy możesz wskazać mi źródło, w którym mogę znaleźć więcej takich wskazówek? – stackoverflowwww
Używanie readelf na przykład wyświetli funkcje, obiekty, symbole używane w pliku binarnym. Mogą one służyć jako podpowiedź do znalezienia używanych bibliotek. Na przykład możesz zobaczyć funkcję Curl_http i wiedzieć, że libcurl jest najprawdopodobniej używany przez plik binarny i jeśli nie jest dynamicznie połączony, musi być połączony statycznie. – ohgodnotanotherone
Jak @Goz i anon wskazują, działa to tylko wtedy, gdy plik binarny nie został usunięty/zawiera informacje o debugowaniu. Nazwy nie są konieczne (i nie są nawet używane) po połączeniu biblioteki statycznej z aplikacją - wszystkie połączenia odbywają się według adresu. –
To nie odpowiada na pytanie. "uruchamianie nm względem tych bibliotek" nie jest możliwe, jeśli nie znasz bibliotek; i są biblioteki używane pośrednio w łączeniu. – kavadias
Jeśli jest to nieznany plik binarny, nie wiemy, jakie biblioteki są obecne. Zatem "uciekanie się do tych bibliotek" brzmi samobójczo. – goldenmean