2009-08-27 11 views

risposta

48

La risposta dipende dalla piattaforma. Sulla maggior parte delle piattaforme, se in uscita dal

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

è vuota, allora o foo.o non era compilato con -fPIC, o foo.o non contiene alcun codice dove -fPIC materia.

+1

ho provato il mio PIC/oggetti non-PIC e questo test non ha funzionato. In effetti, non è elencato nulla. – teambob

+0

questo test ha funzionato per me su un'architettura PPC. –

+1

@teambob Siamo spiacenti, 'objdump' non capisce' --relocs' flag, 'readelf' fa. –

8

Ho appena dovuto eseguire questa operazione su un target PowerPC per trovare quale oggetto condiviso (.so) è stato creato senza -fPIC. Quello che ho fatto è stato eseguire read -d libMyLib1.so e cercare TEXTREL. Se vedi TEXTREL, uno o più file sorgenti che costituiscono il tuo .so non sono stati creati con -fPIC. È possibile sostituire con elfdump se necessario.

Ad esempio,

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

E per aiutare le persone alla ricerca di soluzioni, l'errore mi è stato sempre quando ho incontrato il mio eseguibile è stato questo:

[email protected]:/# ./program: error while loading shared libraries: /usr/lib/libMyLi 
b1.so: R_PPC_REL24 relocation at 0x0fc5987c for symbol 'memcpy' out of range 

Io non so se queste informazioni si applica a tutte le architetture.

Fonte

: blogs.oracle.com/rie

0

Un'altra opzione per distinguere se il programma viene generato opzione -fPIC ingegno:

a condizione che il codice ha -g3 -gdwarf-2 opzione abilitata quando si compila.

altro formato gcc di debug può anche contiene la macro informazioni:

Nota il seguente $ '..' sintassi è assume 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__ 

tale metodo funziona perché manuale gcc dichiara che se -fPIC viene utilizzato, PIC è definita a 1, e se -fPIC utilizzato, PIC è 2.

le risposte suddette controllando il GOT è th e il modo migliore. Perché il prerequisito di -g3 -gdwarf-2 credo che venga usato raramente.

2

Presumo, quello che vuoi veramente sapere è se una libreria condivisa è composta da file oggetto compilati con -fPIC.

Come già accennato, se ci sono TEXTREL, quindi -fPIC non è stato utilizzato.

C'è un grande strumento chiamato scanelf che può mostrare i simboli che hanno causato il trasferimento di testo.

Ulteriori informazioni sono disponibili al HOWTO Locate and Fix .text Relocations TEXTRELs.

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

Questo dovrebbe funzionare la maggior parte del tempo.

+1

Sembra così semplice, ma la libreria di fronte a me è rilocabile, ha un sacco di voci R_386_JUMP_SLOT nella sua tabella .rel.plt, ma ha 0x0 per Flags. Forse funziona solo su mips32. – James

1

-fPIC significa che il codice sarà in grado di eseguire in indirizzi diversi dall'indirizzo per cui è stato compilato.

di farlo, disasambler sarà simile a questa ....

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

ora a Ax abbiamo un offset che abbiamo bisogno di aggiungere a qualsiasi accesso alla memoria.

load bx, [ax + var_address} 
Problemi correlati