chargement dynamic de la bibliothèque: un moyen facile de comprendre le temps d’exécution des symboles non résolus

Je travaille sur un énorme projet qui charge des bibliothèques dynamics à l’exécution en utilisant ACE_DLL :: open.

La bibliothèque est située et essaie de s’ouvrir mais échoue sur mmap (ci-dessous est le strace) en raison de symboles non résolus. Je sais avec certitude que c’est à cause de symboles non résolus et en exécutant nm je pourrais obtenir la liste de tous les symboles non résolus. Le problème est qu’il y a des tonnes de symboles non résolus au moment de la compilation, qui doivent à leur tour être résolus au moment de l’exécution, donc nm n’est pas très utile car je dois parcourir tous les symboles un par un.

Existe-t-il une manière intelligente de déterminer exactement ce qui provoque le chargement du .so

open("libxxxxxxx_d.so", O_RDONLY) = 29 read(29, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300w\3\0004\0\0\0"..., 512) = 512 fstat64(29, {st_mode=S_IFREG|0755, st_size=10130306, ...}) = 0 mmap2(NULL, 373832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 29, 0) = 0xffffffffed5f5000 mmap2(0xed64e000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 29, 0x59) = 0xffffffffed64e000 close(29) = 0 munmap(0xed5f5000, 373832) = 0 munmap(0xed5cc000, 167764) = 0

Définissez ACE_DEBUG=1 comme variable d’environnement, la journalisation ACE doit alors imprimer un message de débogage indiquant quel symbole n’est pas résolu. Ceci est juste un symbole, donc vous avez probablement besoin de plusieurs itérations pour trouver tout

Le fragment strace ne montre aucun type de défaillance. L’ouverture de la bibliothèque partagée semble avoir été un succès.

Je ne suis pas familier avec ACE_DLL::open que vous mentionnez, mais j’ai trouvé des informations ici et il semble que ce ne soit qu’une mince couche autour de dlopen() et de ses amis.

Maintenant, il est possible que la bibliothèque ne s’ouvre pas en raison de symboles non résolus sur dlopen() mais uniquement si RTLD_NOW est utilisé. Le problème est que le message d’erreur ne mentionne qu’un symbole problématique.

Si vous ne voulez pas parcourir la liste des symboles objdump -T par nm ou objdump -T ou similaire pour la bibliothèque, le plus simple est de lier votre application à la bibliothèque en question et de voir ce que l’éditeur de rapport signale comme étant des erreurs. Il devrait énumérer tous les problèmes au lieu d’un seul. Tout d’abord, ajoutez un code d’espace réservé à votre application qui référencera tout symbole valide de la bibliothèque (pour forcer la -lxxxxxxx_d de la bibliothèque par l’éditeur de liens), puis ajoutez -lxxxxxxx_d à vos opérations de lien.

Cette commande signalera les fonctions et objects manquants dans une bibliothèque partagée:

 ldd -r your_library.so

Voir man ldd pour plus d’informations.