2010-10-05 18 views
6

Załóżmy, że mam projekt z tuzinem różnych modułów, które generują jedną wypadkową bibliotekę DLL. Jak mogę to przeanalizować, aby zidentyfikować rzeczywisty rozmiar pliku każdy moduł/funkcje przyczyniają się? Wiem, że to może nie być możliwe z wersją Release, w której usunięto wiele informacji, ale co z tym, że mam pełne źródło i mogę wykonać kompilację Debug?Analizowanie plików .exe/.dll (Windows PE) dla nadawców kodu

Ponadto, jeśli gdzieś są gdzieś duże zmienne statyczne, czy istnieje sposób, w jaki mogę je łatwo zlokalizować?

Dodatkowe pytanie: A pliki Linux ELF?

+0

dumpbin should IMHO show you big global/statics. – valdo

+0

@valdo jakieś szczegóły, jak to zrobić? Zbadałem trochę i nie mogłem tego rozgryźć. – kizzx2

Odpowiedz

4

Za każdym razem, gdy jestem zaangażowany w identyfikację nadużywania, zwykle zaczynam od dumpbin w systemie Windows. Zwykle, pisząc narzędzie do sprawdzenia każdego modułu obiektu poprzez dumpbin, przeanalizuj wyniki. Jest to proces powtarzalny i może zająć sporo czasu.

Dla kompilacji debugowania z PDB Sizer może generować przydatne raporty.

Adrian ma tutaj kilka przydatnych wskazówek. Minimizing Code Bloat for Faster Builds and Smaller Executables i narzędzie o nazwie SymbolSort, aby pomóc. Źródło w C# jest dołączone do SymbolSort, więc może być dobrym miejscem do rozpoczęcia, jeśli nie pomoże SymbolSort.

Dla ELF wyjście z nm i objdump jest dobrym punktem wyjścia.

+0

To jest absolutnie fantastyczne! Mają tę głupią 24-godzinną polisę na nagrodę: P – kizzx2

+0

Wystarczy spojrzeć na 'nm -S'. Jaki prosty problem, który jest tak mało znany do rozwiązania w systemie Windows: P – kizzx2

Powiązane problemy