2010-10-05 18 views
6

Digamos que tengo un proyecto con una docena de módulos diferentes que producen una DLL resultante, ¿cómo puedo analizarla para poder identificar el tamaño de archivo real que cada módulo/función contribuye? Sé que podría ser imposible con una compilación de versión en la que se ha eliminado mucha información, pero ¿qué tal si tengo la fuente completa y puedo hacer una compilación de depuración?Analizar archivos .exe/.dll (Windows PE) para código de inflado

Además, si hay grandes variables estáticas definidas en algún lugar, ¿hay alguna manera de localizarlas fácilmente?

Pregunta extra: ¿Qué hay de los archivos ELF de Linux?

+0

dumpbin debería en mi humilde opinión mostrarle grandes global/estática. – valdo

+0

@valdo ¿algún detalle sobre cómo hacerlo? He explorado un poco y parece que no puedo entenderlo. – kizzx2

Respuesta

4

Cada vez que he estado involucrado en la identificación de hinchazón, generalmente comienzo con dumpbin en Windows. Por lo general, al escribir una herramienta para examinar cada módulo de objetos a través de dumpbin, se analiza la salida. Tiende a ser un proceso iterativo y puede llevar bastante tiempo.

Para compilaciones de depuración con PDB Sizer puede generar informes útiles.

Adrian tiene alguna orientación útil aquí. Minimizing Code Bloat for Faster Builds and Smaller Executables y una herramienta llamada SymbolSort para ayudar. La fuente en C# se incluye con SymbolSort, por lo que puede ser un buen lugar para comenzar si SymbolSort no ayuda.

Para ELF, la salida de nm y objdump es un buen punto de partida.

+0

¡Esto es absolutamente fantástico! Tienen esta política estúpida de 24 horas para la recompensa: P – kizzx2

+0

Acabo de echar un vistazo a 'nm -S'. Qué problema tan simple de resolver en Windows: P – kizzx2

Cuestiones relacionadas