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

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

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.

Solo tenía que hacer esto en un objective 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 architectures.

Fuente: blogs.oracle.com/rie

Supongo que lo que realmente quiere saber es si una biblioteca compartida está compuesta de archivos de objetos comstackdos 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 .

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

Esto debería funcionar la mayor parte del tiempo.

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

Para hacerlo, el desambilador se verá así …

 call get_offset_from_comstacktion_address get_offset_from_comstacktion_address: pop ax sub ax, ax , &get_offset_from_comstacktion_address 

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

 load bx, [ax + var_address} 

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

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

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

Tenga en cuenta que la siguiente syntax $ ‘..’ 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 -xc - 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.