2010-10-05 2 views
6

Предположим, у меня есть проект с десятком различных модулей, которые производят одну результирующую DLL, как я могу ее проанализировать, чтобы я мог определить фактический размер файла, который каждый модуль/функции? Я знаю, что это может быть невозможно в сборке Release, где много информации было удалено, но как насчет того, если у меня есть полный источник и вы можете сделать сборку Debug?Анализ файлов .exe/.dll (Windows PE) для разрастания кода

Кроме того, если существуют большие статические переменные, определенные где-то, есть ли способ, с помощью которого я могу их легко найти?

Бонусный вопрос: Как насчет файлов Linux ELF?

+0

dumpbin должно ИМХО показать вам большой глобальный/статика. – valdo

+0

@valdo какие-либо подробности о том, как это сделать? Я немного изучил и, похоже, не понял этого. – kizzx2

ответ

4

Всякий раз, когда я участвовал в идентификации наворотов, я обычно начинаю с dumpbin в Windows. Обычно, записывая инструмент для изучения каждого объектного модуля через dumpbin, затем анализируйте выход. Он имеет тенденцию быть итеративным процессом и может занимать достаточно много времени.

Для отладочных сборников с PDB Sizer можно создавать полезные отчеты.

У Адриана есть полезное руководство здесь. Minimizing Code Bloat for Faster Builds and Smaller Executables и инструмент под названием SymbolSort. Источник в C# включен в SymbolSort, поэтому может быть хорошим местом для запуска, если SymbolSort не помогает.

Для ELF выходной сигнал nm и objdump являются хорошей отправной точкой.

+0

Это абсолютно фантастично! У них есть эта глупая 24-часовая политика за щедрость: P – kizzx2

+0

Просто взглянул на 'nm -S'. Какая простая проблема, которая так непонятна для решения Windows: P – kizzx2