Après avoir lié une bibliothèque de partage (.so) avec dlopen, comment pouvons-nous connaître la taille de l'objet partagé lié, c'est-à-dire jusqu'à ce que le décalage de la poignée renvoyée par dlopen soit la bibliothèque partagée allouée.Comment connaître la taille de l'allocation de mémoire d'un objet partagé lié lors de l'exécution?
La liaison dynamique de la bibliothèque partagée est un processus d'espace utilisateur complet. Vous pouvez le faire vous-même: analyser les en-têtes ELF du fichier, mettre le fichier en mémoire, faire la liaison dynamique avec des symboles non définis de la bibliothèque partagée, etc. pp. Ensuite, vous savez exactement où se trouvent les parties de la bibliothèque. Mais GNU libdl ne fournit aucune information à ce sujet.
Une autre option consiste à dlopen() la bibliothèque et à analyser/proc/self/maps pour elle. Il a généralement plusieurs correspondances avec des autorisations d'accès différents (code, Rodata, rwdata, etc.) en fonction de l'en-tête elfe comme ça:
7fd6298f0000-7fd6298f5000 r-xp 00000000 fd:00 393441 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7fd6298f5000-7fd629af4000 ---p 00005000 fd:00 393441 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7fd629af4000-7fd629af5000 r--p 00004000 fd:00 393441 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7fd629af5000-7fd629af6000 rw-p 00005000 fd:00 393441 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
Cela devrait fournir toutes les informations dont vous avez besoin.
Pourquoi avez-vous besoin de le savoir? – Barmar
L'objet partagé ne doit pas nécessairement être un seul bloc de mémoire. Il peut avoir différents segments pour le texte, les données, BSS, tout comme un fichier objet exécutable. – Barmar
Pouvons-nous connaître les offsets pour les données? Je veux faire une table de décalage pour les fonctions et les données de la bibliothèque partagée. –