gcc binarios compilados con diferentes tamaños?

Si el mismo código se genera en diferentes momentos w/gcc, el binario resultante tendrá diferentes contenidos. De acuerdo, no estoy loco por eso, pero eso es lo que es.gcc binarios compilados con diferentes tamaños?

Sin embargo, recientemente me encontré con una situación en la que el mismo código, construido con la misma versión de gcc, genera un binario con un tamaño diferente al de una compilación anterior (por unos 1900 bytes).

¿Alguien tiene alguna idea de lo que puede estar causando cualquiera de estas situaciones? ¿Es esto algún tipo de problema ELF? ¿Hay alguna herramienta (aparte de ldd) que pueda usarse para volcar el contenido de los binarios para ver qué es exactamente diferente?

Gracias de antemano.

Fuente

2009-08-14 BillTorpey

Un ejemplo replicable ayudaría:

¿Utiliza otras bibliotecas externas?
¿Se vincula de forma estática o dinámica?
¿Cambió banderas como -O o -s?

Fuente

2009-08-14 13:41:34

Banderas del compilador es lo primero que se me vino a la mente también. Especialmente algo así como -O. –

Esto ha sido una especie de asked before, y la respuesta es que el estado interno del compilador puede también ser diferente en diferentes carreras del compilador, lo que puede resultar en código diferente sido emitidos y por lo tanto tener diferente tamaño.

Fuente

2009-08-14 13:44:48

Antes de que los monos cercanos se pongan contentos con esto, debo señalar que la pregunta era acerca de obtener diferentes exe cuando se compilan en diferentes plataformas (con sabor a Windows). Esta pregunta se trata de obtener diferentes exe en la misma plataforma con el mismo compilador. –

... Dicho esto, la respuesta que dio allí es realmente buena aquí. –

Bueno, se supone que las plataformas son idénticas. (Todo está construido a partir de servidores de compilación dedicados). Entonces, lo que estamos tratando de averiguar es dónde ha ido mal. – BillTorpey

objdump es probablemente el programa que está buscando para volcar el contenido de los binarios.

objdump -h le mostrará las secciones y sus tamaños, por lo que debería poder ver dónde está ocurriendo el cambio de tamaño y luego profundizar más para ver por qué.

Fuente

2009-08-14 13:49:59 caf

Los compiladores DEC VMS solían hacer esto también. La razón es que el optimizador podría hacer un mejor trabajo cuanto más RAM libre tenga para trabajar. Obviamente, es muy difícil tener exactamente la misma cantidad de RAM libre disponible cada vez que compila.

Recuerdo que algunas personas quedaron horrorizadas por esto. Este fue particularmente el caso para las personas a las que les gustaba verificar los cambios en la fuente al diferir los binarios resultantes. Mi consejo entonces, como ahora, es superarlo. Fuentes que puedes "dif". Para los binarios, la única garantía es que ambos ejecutables compilados a partir de los mismos archivos fuente harán lo que usted les indicó que hicieran.

Fuente

2009-08-14 14:10:43

Creo que es muy importante que cuando le proporcione al compilador el mismo código fuente y la misma configuración de compilación, siempre muestre exactamente el mismo ejecutable, byte por byte. De lo contrario, si hay un error en el optimizador, es posible que termine con algunas compilaciones "funcionando" y otras "no", basadas únicamente en la cantidad de RAM que pasó a estar libre en el momento en que se creó el ejecutable. .. realmente una pesadilla para depurar! Incluso si el compilador no tiene errores, algunas de sus compilaciones se ejecutarán más rápido que otras, a pesar de que el código fuente sea el mismo en todos los casos. –

Es posible que desee esto, pero como TED y yo mismo hemos señalado, no puede tenerlo. –

¿Desea proporcionar una referencia que demuestre que gcc tiene este comportamiento roto, ya que de eso se trata la pregunta del OP? – caf

Además del compilador, debe verificar las bibliotecas estándar con las que establece un vínculo. Verifique su versión y verifique que no hayan cambiado.

Fuente

2009-08-14 16:53:49

Una posible razón para una diferencia de tamaño entre compilaciones idénticas es que no puede haber información de tamaño variable almacenada en el binario. Algunos ejemplos:

el compilador puede estar poniendo información de la ruta/nombre de los archivos en la compilación invoved, ya sea para la depuración de información o debido al uso de la __FILE__ macro. Es posible que pueda hacer esto por sus propios propósitos que no tienen nada que ver con ninguna de esas cosas. Si la construcción ocurre en diferentes máquinas con incluso una estructura de directorio ligeramente diferente, esto puede explicar las diferencias en el binario.
de forma similar para la fecha/hora de la compilación, aunque espero que estos encuentren su camino en el binario con mucha menos frecuencia (¿pero qué sé yo?).Si esto fuera un factor contribuyente, verías diferentes tamaños incluso desde construcciones idénticas en la misma máquina, solo en diferentes momentos.

Estas cosas se reducen a las diferencias en el estado de la máquina de compilación, as Neil Butterworth pointed out.

Fuente

2009-08-14 16:54:58

He logrado solucionar las cosas, al menos para mi satisfacción, y quería transmitir lo que he encontrado.

Uso de readelf, (readelf -a -W) Creé un informe que enumeraba los contenidos de ambas compilaciones y las comparé (utilizando Beyond Compare). Esto demostró que un par de símbolos adicionales se obtenían de las libs de impulso.

En realidad, estábamos construyendo contra una versión diferente de una biblioteca dependiente y no nos dimos cuenta. No se hace daño en este caso, pero es bueno saber qué le ocurre a su ejecutable.

Gracias a todos por las respuestas reflexivas.

Fuente

2009-08-14 17:22:41 BillTorpey

gcc binarios compilados con diferentes tamaños?

Respuesta

Cuestiones relacionadas