Discussion :

[darkman19320]

Bonjour tout le monde,

Je cherche à trouver un moyen pour extraire l'ensemble des méthodes présentes dans une bibliothèque dynamique (C++) (.so ou .dll). Pour le moment, j'utilise des outils externes comme nm sous linux ou Dependency Walker pour les lister.

J'aimerais pouvoir charger ces méthodes de manière dynamique directement depuis un programme. Est-ce qu'il y a des bibliothèques open source qui permettent ça?

Je pensais à une interface de ce genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
//allMethods comprend les différentes méthodes avec leurs arguments associés
std::vector<Methods> allMethods = listMethods("myBiblio.so"); //listMethods("myBiblio.dll");
//allMethods[0].functionType() retournerait un std::function avec le bon paramètre de retour ainsi que les bons arguments
allMethods[0].functionType() func1 = loadMethod<allMethods[0].functionType()>(allMethods[0].name());

Il faudra bien sûr que je trouve une méthode pour convertir un string en type (int, double, etc....) voir en classe. (c'est le principe de réflexion non?)

Merci pour tout.

[bacelar]

Ce que je vais affirmer ici n'est valable que pour les dll, je ne connais absolument pas les .so.

Dans une dll "classique", il n'y aucune information autre que les noms décorés avec un indice dans une table d'offset dans le code.
https://msdn.microsoft.com/en-us/magazine/cc301808.aspx
Pour avoir la liste des fonctions exportées, il faut donc juste lire la structure "IMAGE_EXPORT_DIRECTORY" dans la partie en-tête d'un fichier au format PE.

Si vous voulez accéder aux autres informations (nombres de paramètres, types de paramètres, type de retour), il faut que vous ayez accès aux informations des debuggings, que chaque chaine de compilation traite et stocke de manière différente (fichier pdb, section de données en CodeView7).
Les dll "imagehlp.dll" et "dbghelp.dll" permettent de lire ces informations sans tout interpréter à la main (en plus, c'est fonction du compilateur).


Dependency Walker utilise le mangling de VS pour récupérer la signature des méthodes C++, ça ne marche donc qu'avec du code écrit en C++ compilé avec VS.

[darkman19320]

Merci pour cette réponse détaillée.

Je voulais à la base ne fournir qu'une bibliothèque dynamique à mon application qui "interprèterait" automatiquement l'ensemble des méthodes fournies par le plugin.

Au vu de la complexité et surtout de la contrainte de devoir compiler les bibliothèques (plugins) en debug pour avoir accès aux paramètres, je vais plutôt me tourner vers une méthode qui listera les paramètres ainsi que les noms des fonctions associées (enfin, quelque chose dans le genre).

[Bousk]

Hello,

peut-être que tu peux prendre le problème à l'envers et utiliser le scripting.
Tu fournis une API en script (Python, LUA, ..) depuis ton appli, un moyen de faire comprendre à l'application que tel fichier c'est un script de plugin et qu'il doit appeler. Dans le script, l'utilisateur peut manoeuvrer l'appli avec ton API.

[darkman19320]

Effectivement, je pourrais faire ça mais le but était plus d'éviter d'avoir un autre fichier en plus de la bibliothèque dynamique. En plus, je suis dans un domaine (médical) où l'on ne souhaite surtout pas que l'utilisateur puisse faire des "bidouilles" et risque de créer un comportement inattendu.

[ternel]

Il suffit de ne pas lui donner accès à tout.
Avec du scripting, tu ne donnes accès qu'à une partie des fonctions/variables.

Ca peut être très contrôlé.

[bacelar]

surtout de la contrainte de devoir compiler les bibliothèques (plugins) en debug

Attention, avoir les informations de debuggin, cela ne veut pas dire compilé en DEBUG.
Vous pouvez générer ces informations même en RELEASE.
Vous pouvez même utiliser des options pour que ces informations soient intégrées au fichier (CodeView7, ...).

Mais, franchement, pour une architecture de plug-Ins, c'est vraiment super-mega-over-kill.

Si vous ne voulez pas utiliser des framework tout fait comme COM, vous pouvez vous contentez d'une simple API C avec quelques fonctions défini.

Votre exécutable scanne un répertoire à la recherche des Dll, les chargent et appelle les fonctions C pour dialoguer avec le Plug-Ins.
L'API est immuable et connu de l'exécutable, les Dll ci conforme, et puis c'est tout.

Les mécanismes de DelayLoading peuvent peut-être simplifier le travail fastidieux de GetProcAddress, etc..., surtout si vous n'avez qu'une Dll Plug-Ins par fonctionnalité.

[darkman19320]

Attention, avoir les informations de debuggin, cela ne veut pas dire compilé en DEBUG.

Merci pour cette information. Je ne suis pas très familier avec le compilateur de Visual Studio ou tout simplement le développement sur Windows.

Je ne pourrais pas utiliser COM puisque l'application devra être portable donc je me tournerai sur une API C avec quelques fonctions définies et surtout un ensemble de types (objets) qui pourront être passés et retournés par les fonctions. Les plug-ins ne seront pas interdépendant du coup, cela simplifiera largement les choses.

[bacelar]

et surtout un ensemble de types (objets) qui pourront être passés et retournés par les fonctions

Aïe, ça casse tout l'intérêt des plug-Ins votre truc.

Les plug-ins ne seront pas interdépendant du coup, cela simplifiera largement les choses.

Simplifier un truc au point qu'il devient inutile, c'est bizarre comme stratégie.

Il est possible faire une API avec des objets en wrappant l'API C avec un peu de code C++ coté exécutable.