Modo de compilación: RelWithDebInfo

Question

Creo que entiendo la diferencia entre los modos de compilación Release y Debug. Las diferencias principales son que en el modo de depuración, el ejecutable producido no está optimizado (ya que esto podría dificultar la depuración) y se incluyen los símbolos de depuración.

Al construir PCRE, una de las dependencias externas para WinMerge, noté un modo de compilación que no había visto antes: RelWithDebInfo.

La diferencia entre Debug y RelWithDebInfo se menciona aquí: http://www.cmake.org/pipermail/cmake/2001-October/002479.html. ejercicio: "RelwithDebInfo es bastante similar al modo Release. Produce código completamente optimizado, pero también crea la base de datos del programa e inserta información de línea de depuración para darle al depurador una buena oportunidad para adivinar dónde está en el código en cualquier momento. "

Esto suena como una muy buena idea, sin embargo, no es necesariamente obvio cómo configurarlo. Este enlace describe cómo habilitar esto para VC++: http://www.cygnus-software.com/papers/release_debugging.html

¿Me falta algo, o no tiene sentido compilar todos los códigos de versión como RelWithDebInfo?

Answer 1

Me estoy perdiendo algo, o tiene no tiene sentido para compilar todo el código de liberación como RelWithDebInfo?

Depende de cuánto confíe en su cliente la información de depuración.

Información adicional:

gcc codifica la información de depuración en el código objeto.

Aquí es el equivalente AP del gcc:

How to generate gcc debug symbol outside the build target?

Nota, que cmake no parece apoyar este enfoque fuera de la caja.

Answer 2

Por lo que a mí respecta, enviar código a los clientes sin tener los símbolos de depuración correspondientes almacenados en la empresa es una receta para la pérdida de cabello cuando se trata de problemas de producción de depuración.

Depuración Las compilaciones de versión con símbolos de depuración raras veces son diferentes de depurar compilaciones de depuración, por lo que recomiendo siempre hacerlo.

Dicho esto, no sé si hay algún inconveniente. Sería interesante escuchar, si es así.

Answer 3

El código de producción no necesita la saturación de tamaño que lleva la información de depuración.

Answer 4

Una vez que haya intentado depurar una versión de lanzamiento optimizada, sabrá por qué esto es algo que solo quiere hacer cuando no hay otra salida.

Básicamente, veo dos casos en los que necesitará esta:

• tiene un problema que no aparece en versiones de depuración, así que hay que depurar un comunicado de construir
• Usted tiene una bloquearse en un cliente y utilizar la información de depuración almacenada localmente para comprender el bloqueo.

No sé ustedes, pero tuve que depurar el código de lanzamiento dos o tres veces en la última década y pude trabajar en empresas donde los bloqueos en los clientes no fueron un problema.

Sí, probablemente también sea una buena idea tener información de depuración para las compilaciones de lanzamiento, pero VS no configura las cosas de esta manera y para los dos casos en cada década donde lo necesita no vale la pena establecerlo esto de forma manual todo el tiempo. Como CMake lo da gratis, hazlo.

Answer 5

Incluso cuando se genera información de depuración para la versión de lanzamiento, es mucho menos útil para la depuración que para la creación de depuración. El motivo es que muchas variables y expresiones intermedias se optimizan y, por lo tanto, no están disponibles en el depurador.