relocalisations de texte malgré -fPIC?

J’essaie de recomstackr une stack logicielle de taille décente (doubango) pour ARM. Au bout de deux semaines, je pensais avoir finalement réussi car les bibliothèques relocalisées ne les avaient plus pour armeabi , armv5te , armv7-a . Cependant, armv7-a-neon toujours …

Je sais que la liaison avec des bibliothèques statiques ou des bibliothèques partagées contenant des déplacements de texte les introduira également dans ma bibliothèque. Pour lutter contre cela, vous -fPIC utiliser -fPIC dans ses CFLAGS tout en recompilant tout pour créer un code indépendant de la position. Tout ce qui est fait, j’ai également construit FFMPEG sans relocalisation de texte …

Ce que je ne comprends pas, c’est ceci: si j’utilise le même ensemble de fichiers source pour toutes les arches et vérifie manuellement à la main si les fichiers .a comportent des relocalisations de texte, pourquoi n’existe-t-il qu’un seul déplacement de texte ARMv7 NEON?

Je vérifie en utilisant readelf comme si readelf -a | grep TEXTREL readelf -a | grep TEXTREL pour les .a et .so .

 devshark@ubuntu:~/SCRATCH/doubango_env/doubango/android-projects/output/gpl/armv7-a-neon/lib$ readelf -a libtinyWRAP.so | grep TEXTREL 0x00000016 (TEXTREL) 0x0 0x0000001e (FLAGS) SYMBOLIC TEXTREL BIND_NOW 

Comment trouver le coupable qui a introduit les déplacements de texte dans ma bibliothèque armv7neon .so ?

J’utilise NDK r12b. Voici un pastebin de la sortie complète de la construction: OK, pas de pastie ni de pastebin car ils ne permettent pas 2,1 Mo de texte.

Génial. Alors, des idées pourquoi les délocalisations de texte apparaissent uniquement pour NEON?

La question pourrait être similaire à celle-ci, sauf que je n’ai pas de relocalisation pour x86 non plus. Pourquoi NDK génère-t-il une bibliothèque partagée pour x86 avec déplacement de texte même après la définition de l’indicateur -fPIC?

Si tout est construit avec -fPIC , les relocalisations de texte restantes se font généralement dans un assemblage écrit à la main.

Il semble que ffmpeg ait des problèmes de déplacement de texte avec son code assembleur: