Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

117
Views
Diferencia en md5sums en dos archivos de objetos

Compilo dos veces los mismos archivos .c y .h y obtengo archivos de objetos con el mismo tamaño pero diferentes md5sums. Aquí está la única diferencia con objdump -d :

1) cpcidskephemerissegment.o: file format elf64-x86-64

 Disassembly of section .text: 0000000000000000 <_ZN68_GLOBAL__N_sdk_segment_cpcidskephemerissegment.cpp_00000000_B8B9E66611MinFunctionEii>:

2) cpcidskephemerissegment.o: file format elf64-x86-64

 Disassembly of section .text: 0000000000000000 <_ZN68_GLOBAL__N_sdk_segment_cpcidskephemerissegment.cpp_00000000_8B65537811MinFunctionEii>:

cual puede ser la razon? ¡Gracias!

over 4 years ago · Santiago Trujillo
3 answers
Answer question

0

Las razones pueden ser muchas:

  • Usando macros como __DATE__ y __TIME__
  • Incorporación de contadores que se incrementan para cada compilación (el kernel de Linux hace esto)
  • Marcas de tiempo (o cantidades variables similares) incrustadas en la sección ELF de .comments . Un ejemplo de un compilador que hace esto es el compilador xlC en AIX.
  • Nombres diferentes como resultado de la manipulación de nombres (por ejemplo, C++)
  • Cambios en las variables de entorno que están afectando el proceso de construcción.
  • Error(es) del compilador (aunque improbable)

Para producir compilaciones un poco idénticas, puede usar el parámetro -frandom-seed de GCC. Hubo situaciones en las que podía romper cosas antes de GCC 4.3, pero GCC ahora convierte funciones definidas en espacios de nombres anónimos en símbolos estáticos. Sin embargo, siempre estará seguro si compila cada archivo usando un valor diferente para -frandom-seed , la forma más sencilla es usar el nombre del archivo como semilla.

over 4 years ago · Santiago Trujillo Report

0

Supongo que el compilador no sabía cómo nombrar este espacio de nombres y usó la ruta al archivo fuente más algún número aleatorio.

El compilador debe garantizar que un símbolo en un espacio de nombres sin nombre no entre en conflicto con ningún otro símbolo en su programa. De forma predeterminada , esto se logra tomando el nombre de archivo completo de la fuente y agregándole un valor hash aleatorio (es legal compilar la misma fuente dos veces (por ejemplo, con diferentes macros) y vincular los dos objetos en un solo programa, y el espacio de nombres sin nombre los símbolos aún deben ser distintos, por lo que usar solo el nombre del archivo de origen sin la semilla no es suficiente).

Si sabe que no está vinculando el mismo archivo fuente más de una vez y desea tener un archivo de objeto idéntico en bits al volver a compilar, la solución es agregar -frandom-seed="abcd" a su línea de compilación (reemplazar "abcd" con lo que quieras; es común usar el nombre del archivo como el valor de la semilla aleatoria). Documentación aquí .

over 4 years ago · Santiago Trujillo Report

0

¡Finalmente he encontrado la respuesta!

El comando c++filt dio el nombre original de la función:

{unnamed namespace}: MinFunction(int, int)

En la fuente estaba:

 namespace { MinFunction(int a, int b) { ... } }

¡Nombré el espacio de nombres y obtuve una suma de verificación estable del archivo de objeto! Como supongo, el compilador no sabía cómo nombrar este espacio de nombres y usó la ruta al archivo fuente más algún número aleatorio.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!