Les codes fantastiques : lib et introspection

Sous Linux, le chargement à l’exécution de bibliothèque partagée repose sur la libdl, et l’appel à la fonction dlopen. L’usage classique est de récupérer un pointeur vers une structure opaque représentant la bibliothèque ouverte par l’appel :

avant de rechercher un symbole en passant ce pointeur et le nom du symbole recherché à la fonction dlsym :

Il existe cependant un autre mode d’utilisation de dlsym qui repose sur un handle réservé, RTLD_DEFAULT, et qui permet de rechercher un symbole parmi les bibliothèques déjà ouvertes par le processus en cours. Cette fonctionnalité, qui est une extension GNU, peut s’avérer très utile pour avoir un comportement conditionnel suivant l’environnement dans lequel on s’exécute.

Jetons un œil au fichier suivant, destiné à être compilé en tant que bibliothèque partagée :

Lorsque la bibliothèque est chargée, la fonction check_in_python va s’exécuter (elle est marquée comme constructor). Si le processus en cours ne contient aucune bibliothèque définissant le symbole Py_GetVersion, elle affichera « not in a python env ». Mais si elle est chargée depuis un processus Python, comme dans le cas suivant, elle affichera des informations de version.

Par exemple, on retrouve ce comportement dans le projet LLVM, pour détecter si le binaire dans lequel une bibliothèque est chargée a été compilé depuis le langage Swift :

En bonus, notons que l’on peut atteindre un résultat semblable, plus rapide, mais moins portable en utilisant les weak symbols :

Cette fois, l’astuce repose sur le comportement par défaut d’un symbole marqué weak et non initialisé : il est mis à zéro. Sauf que si ce symbole est défini dans le processus chargé, il prendra la valeur de ce symbole, ce qui permet de détecter la présence de ce dernier sans passer par la libdl : c’est le dynamic loader qui se charge du travail au chargement du binaire (ce n’est donc pas strictement équivalent à la libdl qui effectue le test au moment où le code est exécuté).