Comment exporter des symboles à partir d'une bibliothèque partagée

Question

J'ai créé une bibliothèque partagée (*.so) en utilisant les fichiers de code objet *.o (C code source) en utilisant le compilateur DRV sur l'hôte de Windows.

je lier cet objet partagé avec une application (en utilisant gcc pour cible ARM sur l'hôte Linux) et obtenir un exécutable, qui en fonctionnement génère des erreurs de segmentation. (Je sais que je dois le débugger!)

Au lieu de créer une bibliothèque partagée, si je crée une bibliothèque statique avec des fichiers même source, et le lien puis avec l'application, puis exécutez l'application, il fonctionne très bien comme prévu.

Alors mes questions sont:

1. Dois-je exporter des symboles (fonctions exportées vers l'application) ou tout autre symbole, explicitement, dans mon fichier source à l'aide des constructions pour que cela fonctionne très bien lorsqu'elle est liée à une application? Ce qui est nécessaire et comment puis-je faire?

2. Comment fonctionne la bibliothèque partagée ?, à savoir se les adresses où les fonctions seront chargées et exécutées, seront données dans la bibliothèque être donnée lorsque la bibliothèque est créée. Comment l'application (main()) résoudre les adresses où les fonctions de la bibliothèque doivent être exécutées?

3. Comment fonctionne une bibliothèque statique, à savoir comment cette spécification d'adresse et de résoudre se produire dans le cas de la bibliothèque statique?

Answer 1

Voilà comment cela fonctionne sur linux:

1) Non, vous ne devez pas faire quoi que ce soit. Vous pouvez toutefois limiter les variables d'exportation avec l'argument de ligne de commande -fvisibility gcc et explicitement les entrées exportées de drapeau avec l'attribut de visibilité.

2) L'exécutable aura une table de toutes les fonctions qu'il importe (ce sont toutes les fonctions avec une visibilité par défaut). Le chargeur / éditeur de liens choisir une adresse pour charger les bibliothèques et à remplir ce tableau juste avant la course, les appels à ces fonctions sont des appels indirects. (Notez que cela est valable pour les objets partagés ainsi)

3) la liaison statique est effectuée sur le lien-temps (ce qui est après la compilation). Les adresses réelles sont substituées dans l'ensemble, et ils sont des appels directs.

Note: Il est la chose appelée PIC (position code indépendant). Autant que je sache, il traite des références aux données / fonctions dans le même objet partagé, de sorte que l'éditeur de liens ne doit pas remplacer la moitié du code de la bibliothèque lors du chargement de la bibliothèque, de la manière que le code ne fait aucune référence absolue à son propres données. Vous pouvez essayer d'expérimenter avec.

Answer 2

1. Vous n'avez pas besoin d'exporter les symboles avec gcc, car elle exporte tous les symboles par défaut; DRV peut ou ne peut pas faire les mêmes, cependant. Vérifiez votre DRV documentation du compilateur (essayez de le configurer pour « sortie « Relocatable ELF ?)

2. bibliothèques partagées sur Linux doivent être délocalisables, comme l'adresse de base est déterminée lors de l'exécution. Génération du code indépendant de la position est idéale, car elle réduit la quantité de travail nécessaire pour déplacer la bibliothèque. Si votre bibliothèque est délocalisables pas plantage (autrement dit, ne bande pas les informations de déplacement de vos fichiers objet avant de la bibliothèque dynamique). Les symboles sont résolus à des adresses lors de l'exécution après l'adresse de base est sélectionnée et les références internes ont été déplacés.

3. Avec les bibliothèques statiques, toute la résolution de symbole, la réinstallation et l'affectation d'adresses de charge arrive au moment de la compilation.

Ma seule supposition serait que d'une certaine manière, le code de votre compilateur éteignait n'est pas délocalisables lors de l'exécution. Il est un mystère pour moi comment cela se passerait-il sans casser des bibliothèques statiques, mais ...

Si vous générez une bibliothèque statique et bibliothèque partagée directement à partir DRV, une option serait d'essayer de convertir cette bibliothèque statique à une bibliothèque partagée:

gcc -shared -o libfoo.so libfoo.a

Si cela aide, puis l'éditeur de liens de la bibliothèque partagée de DRV (ou sa configuration) est probablement cassé.

Answer 3

Savez-vous quoi que ce soit au sujet de la cause de l'accident?

Une possibilité si vous chargez la bibliothèque partagée dynamiquement (par exemple via dlopen()) est que vous assumez que la bibliothèque chargée OK quand il n'a pas, et tentent d'exécuter des fonctions via des pointeurs NULL.