Comment puis-je savoir, avec quelque chose comme objdump, si un fichier objet a été construit avec -fPIC?

Question

Comment puis-je savoir, avec quelque chose comme objdump , si un fichier objet a été construit avec -fPIC ?

Answer 1

La réponse dépend de la plateforme. Sur la plupart des plates-formes, si la sortie de

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

est vide, alors foo.o n'a pas été compilé avec -fPIC , ou foo.o ne contient aucun code où -fPIC important.

Answer 2

J'ai juste eu à le faire sur un PowerPC cible pour trouver des objets partagés (.) a été construit sans -fPIC. Ce que j'ai fait a été exécuté readelf -d libMyLib1.donc, et de regarder pour TEXTREL. Si vous voyez TEXTREL, un ou plusieurs fichiers source de votre .donc, n'ont pas été construits avec -fPIC. Vous pouvez remplacer readelf avec elfdump si nécessaire.

E. g.,

[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]$

Et pour aider les personnes à la recherche de solutions, l'erreur que je recevais quand j'ai couru mon exécutable a ceci:

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

Je ne sais pas si cette info s'applique à toutes les architectures.

Source: blogs.oracle.com/rie

Answer 3

Je suppose, ce que vous voulez vraiment le savoir est de savoir si ou non une bibliothèque partagée est composé de fichiers objet compilé avec-fPIC.

Comme déjà mentionné, si il y a TEXTRELs, puis -fPIC n'a pas été utilisé.

Il est un excellent outil appelé scanelf qui peut vous montrer les symboles qui l'a causé .texte de délocalisations.

Plus d'informations peuvent être trouvées à HOWTO Localiser et Réparer .texte Délocalisations TEXTRELs.

Answer 4

Une autre option pour distinguer si votre programme est généré wit-fPIC option:

à condition que votre code a -g3 -gdwarf-2 option activé lors de la compilation.

d'autres gcc debug format peut également contient la macro info:

Notez les points suivants $'..' la syntaxe est suppose 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__

cette méthode fonctionne parce que le manuel de gcc déclare que si l'option-fpic est utilisé, le PIC est définie à 1, et si l'option-fPIC utilisé, le PIC est de 2.

Les réponses ci-dessus en cochant le GOT est la meilleure façon de faire. Parce que le prerequest de -g3 -gdwarf-2 je suppose que rarement utilisé.

Answer 5

Lorsque vous créez un objet relogeable il doit y avoir une liste de fixer les emplacements pour les appels de fonctions et de variables. Ceci est vrai pour les bibliothèques statiques et dynamiques des bibliothèques. Dans le format ELF la GLOBAL_OFFSET_TABLE (GOT) est réécrit sur le lien pour pointer vers les variables. Il y a une PLT-tête qui est utilisé pour pointer vers les fonctions - mais puisque les processeurs Intel ont un parent instruction de saut il n'est pas nécessaire de réécrire ce tableau. J'ai trouvé quelques informations qui peuvent être utiles: people.redhat.com/drepper/dsohowto.pdf