Saltar al contenido

Visual Studio: información de depuración en la compilación de lanzamiento

Haz todo lo posible por interpretar el código de forma correcta antes de aplicarlo a tu trabajo si tquieres aportar algo puedes dejarlo en los comentarios.

El tamaño del ejecutable debería aumentar mucho menos del 25%.

De hecho, estoy un poco sorprendido de que aumente mucho, pero algunas pruebas rápidas muestran que al menos un gran proyecto de ejemplo (ScummVM) aumenta el .exe de 10,205,184 bytes a 10,996,224 bytes simplemente agregando el /DEBUG opción al paso de enlace (alrededor de un 8% de aumento). /DEBUG se especifica mediante el "Linker | Debugging | Generate Debug Info" opción en el IDE. Tenga en cuenta que esta configuración deberían no tienen efecto en las optimizaciones generadas por el compilador.

Sé que se coloca un puntero al archivo .pdb en el ejecutable, pero no hay mucho de eso. Experimenté un poco y descubrí que habilitar el /OPT:REF La opción del enlazador cambió la diferencia de tamaño a 10 205 184 frente a 10 205 696. Así que el no /DEBUG construir se mantuvo del mismo tamaño, pero el /DEBUG la compilación se redujo a solo 512 bytes más grande (lo que podría explicarse por el puntero a .pdb; tal vez el enlazador se redondea a algún múltiplo de 512 o algo así). Mucho menos del 1% de aumento. Aparentemente, agregando /DEBUG hace que el enlazador mantenga objetos sin referencia a menos que también especifique /OPT:REF. ("Linker | Optimization | References" opción en el IDE).

El programa funcionará bien sin el archivo .pdb; puede elegir enviarlo a los clientes si desea brindar una mejor experiencia de depuración en el sitio del cliente. Si solo desea poder obtener seguimientos de pila decentes, no necesita tener el archivo .pdb en la máquina del cliente; ellos (o alguna herramienta/funcionalidad que proporcione) pueden enviar un archivo de volcado que se puede cargar en un depurador en su sitio con el archivo .pdb disponible y obtenga la misma información de seguimiento de pila port-mortem.

Por supuesto, una cosa que debe tener en cuenta es que deberá archivar los archivos .pdb junto con sus lanzamientos. El paquete "Herramientas de depuración para Windows" (que ahora se distribuye en el SDK de Windows) proporciona una herramienta de servidor de símbolos para que pueda archivar archivos .pdb y recuperarlos fácilmente para su depuración.

El único inconveniente que se me ocurre para distribuir archivos .pdb es que puede facilitar la ingeniería inversa de su aplicación, si eso le preocupa. Tenga en cuenta que Microsoft distribuye símbolos para Windows (utilizando un servidor de símbolos público, así como paquetes de conjuntos de símbolos completos para algunas versiones específicas). Sin embargo, los símbolos que distribuyen pasan por un paso de desinfección que elimina ciertos elementos que consideran sensibles. Puedes hacer lo mismo (o similar) usando el linker /PDBSTRIPPED opción ("Linker | Debugging | Strip Private Symbols" en el IDE). Consulte la documentación de MSDN para obtener detalles sobre lo que elimina la opción. Si va a distribuir símbolos, probablemente sea apropiado usar esa opción.

Según la documentación de Visual Studio 2005 en Visual Studio 2005 Documentación retirada:

/DEBUG cambia los valores predeterminados para la opción /OPT de REF a NOREF y de ICF a NOICF (por lo tanto, deberá especificar explícitamente /OPT:REF o /OPT:ICF).

En mi caso, ayudó cuando habilité ambos:

/O2 /DEBUG /OPT:REF /OPT:ICF

Reseñas y valoraciones

Nos puedes añadir valor a nuestro contenido aportando tu veteranía en los informes.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)


Tags :

Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada.