gcc - library - make shared libraries

¿Cómo puedo decir, con algo como objdump, si un archivo de objeto se ha creado con-fPIC?

Question

¿Cómo puedo decir, con algo como objdump , si un archivo de objeto se ha creado con -fPIC ?

Answer 1

-fPIC significa que el código podrá ejecutarse en direcciones diferentes de la dirección compilada.

Para hacerlo, el desambilador se verá así ...

call get_offset_from_compilation_address
get_offset_from_compilation_address: pop ax
sub ax, ax , &get_offset_from_compilation_address

ahora en ax tenemos una compensación que debemos agregar a cualquier acceso a la memoria.

load bx, [ax + var_address}

Answer 2

La respuesta depende de la plataforma. En la mayoría de las plataformas, si la salida de

readelf --relocs foo.o | egrep ''(GOT|PLT|JU?MP_SLOT)''

está vacío, entonces foo.o no se compiló con -fPIC , o foo.o no contiene ningún código donde -fPIC importa.

Answer 3

Otra opción para distinguir si tu programa se genera con la opción -fPIC:

siempre que su código tenga activada la opción -g3 -gdwarf-2 al compilar.

otro formato de depuración de gcc también puede contener la información de macro:

Tenga en cuenta que la siguiente sintaxis $ ''..'' asume bash

echo $'' main() { printf("%d//n", /n#ifdef __PIC__/n__PIC__/n#else/n0/n#endif/n); }'' | gcc -fPIC -g3
-gdwarf-2 -o test -x c -
readelf --debug-dump=macro ./test | grep __PIC__

tal método funciona porque el manual de gcc declara que si se usa -fpic, PIC se define a 1, y si se usa -fPIC, PIC es 2.

Las respuestas anteriores al marcar el GOT es la mejor manera. Porque la pre-petición de -g3 -gdwarf-2 creo que rara vez se usa.

Answer 4

Solo tenía que hacer esto en un objetivo de PowerPC para encontrar qué objeto compartido (.so) se estaba construyendo sin -fPIC. Lo que hice fue ejecutar readelf -d libMyLib1.so y buscar TEXTREL. Si ve TEXTREL, uno o más archivos de origen que componen su .so no se crearon con -fPIC. Puede sustituir readelf con elfdump si es necesario.

P.ej,

[user@host lib]$ readelf -d libMyLib1.so | grep TEXT # Bad, not -fPIC
0x00000016 (TEXTREL)
[user@host lib]$ readelf -d libMyLib2.so | grep TEXT # Good, -fPIC
[user@host lib]$

Y para ayudar a las personas que buscan soluciones, el error que estaba obteniendo cuando ejecuté mi ejecutable fue este:

root@target:/# ./program: error while loading shared libraries: /usr/lib/libMyLi
b1.so: R_PPC_REL24 relocation at 0x0fc5987c for symbol ''memcpy'' out of range

No sé si esta información se aplica a todas las arquitecturas.

Fuente: blogs.oracle.com/rie

Answer 5

Supongo que lo que realmente quiere saber es si una biblioteca compartida está compuesta de archivos de objetos compilados con -fPIC.

Como ya se mencionó, si hay TEXTREL, entonces -fPIC no se usó.

Existe una gran herramienta llamada scanelf que puede mostrar los símbolos que causaron las reubicaciones de .text.

Se puede encontrar más información en HOWTO Locate and Fix .text Relocations TEXTRELs .

Answer 6

readelf -a *.so | grep Flags Flags: 0x50001007, noreorder, pic, cpic, o32, mips32

Esto debería funcionar la mayor parte del tiempo.