descompilar - elf 32 bit lsb executable

Diferencia en el código independiente de la posición: x86 vs x86-64

Question

Hace poco estaba construyendo una determinada biblioteca compartida (ELF) orientada a la arquitectura x86-64, como esta:

g++ -o binary.so -shared --no-undefined ... -lfoo -lbar

Esto falló con el siguiente error:

la reubicación R_X86_64_32 contra `un símbolo local ''no se puede usar al crear un objeto compartido; recompilar con -fPIC

Por supuesto, significa que debo reconstruirlo como código independiente de la posición, por lo que es adecuado para vincularlo a una biblioteca compartida.

Pero esto funciona perfectamente bien en x86 con exactamente los mismos argumentos de compilación. Entonces la pregunta es, ¿en qué se diferencia la reubicación en x86 de x86-64 y por qué no necesito compilar con -fPIC en el primero?

Answer 1

Es un modelo de código de problemas. De forma predeterminada, el código estático se genera asumiendo que todo el programa permanecerá en la parte inferior 2G del espacio de direcciones de la memoria. El código para las bibliotecas compartidas debe compilarse para otro modelo de memoria, ya sea PIC, o con -mcmodel = large, que se compilará sin hacer esa suposición.

Tenga en cuenta que -mcmodel = large no está implementado en una versión gcc anterior (está en 4.4, no está en 4.2, no sé en 4.3). .

Answer 2

Es un requisito puramente arbitrario que las personas de ABI nos han impuesto. No hay ninguna razón lógica por la que el enlazador dinámico en x86_64 no pueda admitir bibliotecas que no sean PIC. Sin embargo, como x86_64 no está bajo una presión de registro tan horrible como x86 (y tiene mejores funciones para PIC), no conozco ninguna razón significativa para no usar PIC.

Answer 3

He encontrado una explicación bonita y detallada , que se reduce a:

1. x86-64 utiliza el desplazamiento relativo a IP para cargar datos globales, x86-32 no puede, por lo que hace una referencia negativa a un desplazamiento global.
2. El desplazamiento relativo a IP no funciona para las bibliotecas compartidas, ya que los símbolos globales se pueden anular, por lo que x86-64 se descompone cuando no se construye con PIC.
3. Si x86-64 se construyó con PIC, la desreferencia de desplazamiento relativo a IP ahora produce un puntero a la entrada GOT , que luego se elimina la referencia.
4. x86-32, sin embargo, ya usa una desreferencia de un desplazamiento global, por lo que se convierte en una entrada GOT directamente.