El cargador ELF carga segmentos, no secciones; el mapeo de secciones a segmentos está determinado por el script del enlazador utilizado para construir el ejecutable.
El script del enlazador predeterminado no correlaciona las secciones de depuración con ningún segmento, por lo que se omite.
La información del símbolo tiene dos formas: los símbolos estáticos se procesan fuera de banda y nunca se guardan como datos de sección; El vinculador genera tablas de símbolos dinámicos y se agrega a un segmento especial que se carga junto con el ejecutable, ya que debe ser accesible para el vinculador dinámico. El comando strip solo elimina los símbolos estáticos, que de todos modos no se referencian en ningún segmento.
Por lo tanto, puede utilizar la información completa de depuración durante todo el proceso, y esto no afectará el tamaño de la imagen ejecutable en la RAM, ya que no está cargada. Esto también significa que la información no está incluida en los volcados centrales, por lo que tampoco le brinda ningún beneficio aquí.
La utilidad objcopy tiene una opción especial para copiar solo la información de depuración, por lo que puede generar un segundo archivo ELF que contenga esta información y usar binarios eliminados; al analizar el volcado de memoria, a continuación, puede cargar ambos archivos en el depurador:
objcopy --only-keep-debug myprogram myprogram.debug
strip myprogram
Creo que la cuestión se reduce a si los símbolos se cargan en memoria de forma predeterminada o no. Si lo son, esto contribuiría al tiempo de carga y al consumo de memoria. Pregunta interesante, esperando respuestas. +1 – 0xC0000022L
¿Por qué no intentar hacer ambas cosas? –
@unapersson: Es difícil hacer tales pruebas en nuestro entorno, ya que el rendimiento depende en gran medida de factores externos que varían rápidamente. – Johan