[Insoluble] Allocation mémoire pour gen dynamique de code

Voilà j'ai besoin d'appeller des fonctions d'une DLL quelconque (qui peut changer à l'exécution). Grand pb. s'il en est.

Donc mon idée est d'allouer à l'exécution une zone mémoire exécutable
et d'y écrire (à la brutos) les prologues & épilogues ASM (en utilisant un pointeur byte).

En gros, je veux m'affranchir de générer du byte code dans un fichier, faire une édition de lien, lancer un autre exécutable.

Est-ce que ma méthode est viable ? Est-ce que l'on peut faire mieux ? Est-ce que je risque des "General Protection Fault" (comment rendre mon code plus sur ?).

Est-ce que cela posera des pbs. avec des technos plus évoluées comme C++ mangling, COM+, exceptions (C++, structurées), ... Quand est-il des calling conventions, ... ?

A noter que j'ai sous la main une modélisation des prototypes des fonctions de la DLL (dont je connais le nb. de params, ref & value passing, types, ...).

Je connais très mal le sujet, mais je sais qu'il existe des fonctions toutes faites spécifiques à chaque plateforme pour appeler des dll à chaud. Il y a un ou deux tutos sur le site pour linux je crois, et pour windows ça ne doit pas être immensément difficile à trouver. Ca m'a l'air bien plus simple que ce que tu veux faire, ou alors j'ai mal compris.

Il suffit de charger ta DLL ou autre dynamiquement et puis voilà...

Sous linux ça serait dlopen/dlsym etc.

Bon c'est surement que je n'était pas assez clair.

Le nom de la DLL n'est connu qu'à l'exécution.
Le nom de la fonction à appeller n'est connu qu'à l'exécution.
Le nombre de paramètres d'appel n'est connu qu'à l'exécution.
Le type des paramètres ...
Le type de passage des paramètres (par valeur ou par référence) n'est connu ...
...

Est-ce que vous voyez mieux le pb. maintenant ?

Citation:

---

Le nom de la DLL n'est connu qu'à l'exécution.
Le nom de la fonction à appeller n'est connu qu'à l'exécution.

---

Aucun problème.

Citation:

---

Le nombre de paramètres d'appel n'est connu qu'à l'exécution.
Le type des paramètres ...
Le type de passage des paramètres (par valeur ou par référence) n'est connu ...

---

Il n'y aucune notion de type à l'execution, je vois donc mal comment tu ne peux connaître ceux-ci qu'à ce moment-là...

Citation:

---

Envoyé par mchk0123

A noter que j'ai sous la main une modélisation des prototypes des fonctions de la DLL (dont je connais le nb. de params, ref & value passing, types, ...).

---

Pour être plus clair, à l'exécution, j'ai justement une hiérarchie d'instances de classes C++ décrivant la signature de chaque fonction.

Effectivement il n'existe pas dans le langage C++ d'introspection. Mais j'ai recrée moi-même cette notion à l'aide d'une "cuisine" à moi.

Donc pour en revenir à ma question : allocation mémoire & risques encourus à exécuter du code dedans.

Ce qu'il te faut c'est un intérpréteur complet d'un langage de programmation.

Bon je vais poster ma demande dans le forum ASM, j'aurais surement plus de réponses.

Citation:

---

Envoyé par mchk0123

Pour être plus clair, à l'exécution, j'ai justement une hiérarchie d'instances de classes C++ décrivant la signature de chaque fonction.

Effectivement il n'existe pas dans le langage C++ d'introspection. Mais j'ai recrée moi-même cette notion à l'aide d'une "cuisine" à moi.

---

Mouais, t'as des interfaces et/ou des classes abstraites quoi. Je vois toujours pas en quoi ça rend ton problème non-trivial.

Citation:

---

Envoyé par zais_ethael

Mouais, t'as des interfaces et/ou des classes abstraites quoi. Je vois toujours pas en quoi ça rend ton problème non-trivial.

---

Bon c'est surement que je n'était pas assez clair.

Le nom de la DLL n'est connu qu'à l'exécution.
Le nom de la fonction à appeller n'est connu qu'à l'exécution.
Le nombre de paramètres d'appel n'est connu qu'à l'exécution.
Le type des paramètres ...
Le type de passage des paramètres (par valeur ou par référence) n'est connu ...
...

Et puis :

Est-ce que cela posera des pbs. avec des technos plus évoluées comme C++ mangling, COM+, exceptions (C++, structurées), ... Quand est-il des calling conventions, ... ?

Je ne vois pas trop ton problème. Je vais parler avec du vocabulaire windows, mais les mêmes choses existent sous unix, juste avec d'autres noms :

Citation:

---

Le nom de la DLL n'est connu qu'à l'exécution.

---

Pas de problèmes, LoadLibrary prend en paramètres une chaîne de caractères

Citation:

---

Le nom de la fonction à appeller n'est connu qu'à l'exécution.

---

Pas de problèmes, GetProcAddress prend en paramètre une chaîne de caractères. Le plus difficile sera de deviner quel nom passer s'il s'agit de fonctions C++, qui donc seront manglées.

Citation:

---

Le nombre de paramètres d'appel n'est connu qu'à l'exécution.
Le type des paramètres ...
Le type de passage des paramètres (par valeur ou par référence) n'est connu ...

---

En général, on cast l'adresse retournée par GetProcAddress en pointeur de fonction du bon type, et ça marche. Là, c'est moins simple. Mais je suppose que si tu peux mettre en asm sur la pile les bon paramètres, puis faire appeler directement l'adresse, ça devrait aller.

En bref, je ne vois pas pourquoi recoder la fonction de chargement de DLL.

Merci JolyLoic, enfin quelqu'un qui semble comprendre ce que j'essaye de faire. Je sais je suis pas trés clair dans mes explication.

Je ne veux pas recoder ce que sait faire le C/C++ (comme le chargement de la DLL). Je suis fainéant, je vais utiliser ce que j'ai sous la main.

Citation:

---

Envoyé par JolyLoic

... Là, c'est moins simple. Mais je suppose que si tu peux mettre en asm sur la pile les bon paramètres, puis faire appeler directement l'adresse, ça devrait aller.

---

Justement c'est là ou est le pb. Je pensais faire comme ça ; mais ça c'est la vision simplifiée pour processeur x186. Est-ce que je ne dois pas prendre aussi en compte également toutes les dernières technologies :

- cadres de piles
- cadres de pointeurs (tableaux)
- cadres de mémoire allouées
- exceptions structurées et C++
- thread safe
- information de debugging
...

Maitenenant peut-être que je suis trop peureux (ou ignorant du mécanisme ASM soujacent) vis à vis de la liste que je viens de citer, et qu'elle n'a aucun impact sur ce que je veux faire.

Cherche libffi. Mais ca risque de dependre de ton compilateur.

Il me semble que le passage des arguments est relativement standardisé. Il faut juste pouvoir détecter les cas stdcall/thiscall/fastcall, mais ça doit se voir sur la décoration du nom de fonction.
Il me semble que j'avais trouvé pas mal d'info ici.

Merci beaucoup pour ces liens.

Si jamais vous avez aussi de la documentation sur :

- cadres de piles
- cadres de pointeurs (tableaux)
- cadres de mémoire allouées
- exceptions structurées et C++
- thread safe
- information de debugging
...

Je suis preneur (de manière générale tout ce qui explique comment est "décoré" l'ASM compilé à partir du C/C++ : compilos ciblés = VC++, Builder C++, mingw).

Citation:

---

Envoyé par mchk0123

- cadres de piles
- cadres de pointeurs (tableaux)
- cadres de mémoire allouées

---

Qu'est ce ?

Citation:

---

- exceptions structurées et C++
- thread safe
- information de debugging

---

rien à faire de spécial :
- seuls les gestionnaires d'exceptions (try/catch ou __try/__finally) demandent de poser des info particulières sur la pile. Un gestionnaire est installé lorsqu'on rencontre l'instruction try ou __try, mais rien de spécial n'est fait lors de l'appel d'une fonction.
- Thread safe, c'est qu'il y a les bonnes instructions C/C++ au bons endroits, c'est indépendant de tout problème de compilation.
- à ma connaissance, les info de debug sont posées sur la pile par la fonction elle même. Encore rien à faire pour la fonction appelante.

Citation:

---

Je suis preneur (de manière générale tout ce qui explique comment est "décoré" l'ASM compilé à partir du C/C++ : compilos ciblés = VC++, Builder C++, mingw).

---

Sur l'inplémentation des exceptions (VC++), j'ai les 2 liens suivants :
http://www.codeproject.com/cpp/exceptionhandler.asp
http://www.microsoft.com/msj/0197/ex...exception.aspx
Et je suis intéressé par une doc équivalente pour mingw.

Je doute sérieusement que ton projet nécéssite tant de complexité.
Tu devrais peut-être t'interroger sur ta conception, il y a bien peu de choses que le bon vieux polymorphisme objet ne peut pas faire.
C'est quoi ton projet au fait?

Citation:

---

Envoyé par zais_ethael

Je doute sérieusement que ton projet nécéssite tant de complexité.
Tu devrais peut-être t'interroger sur ta conception, il y a bien peu de choses que le bon vieux polymorphisme objet ne peut pas faire.
C'est quoi ton projet au fait?

---

Le cas habituel pour avoir besoin de ca est quand on fait un interpreteur qui est capable de charger des lib dynamiques.

Et oui !

...

Et moi qui voulais avancer masqué ... C'est râté.

Donc mon projet est effectivement un interpreteur d'expressions mathématiques simple avec pleins de DLLs non uniformisées de fonctions mathématiques.

Comme je n'ai pas envie de recompiler l'interpreteur à chaque nouvelle DLLs (parce qu'il y en aura d'autres), je n'ai pas vraiment le choix.

A moins de passer par des hacks comme intégrer (embedding) un compilateur C, ... etc.

Justement, en concevant ton applic différamment tu n'aurais pas ce genre de problème.
Imaginons que ces fonctions aient l'allure suivante:

Code:

---

1 2 3

int modulo(int,int); float exponent(float,int); int factorielle(int);

---

Tu vas effectivement devoir jouer avec la pile pour parvenir à tes fins.
Mais imaginons plutôt que toutes ces fonctions prennent le même argument, par exemple un vecteur d'objets A, A contenant un int pouvant prendre quelques valeurs définies dans une énumération et un void*, et renvoient toutes un objet A.

Code:

---

1 2 3

A modulo(vector<A>); A exponent(vector<A>); A factorielle(vector<A>);

---

Si tu conçois une sorte de langage dynamiquement typé, te voila avec des appels de fonction qui prennent un nombre quelconque d'arguments et renvoient une valeur.

Citation:

---

Envoyé par zais_ethael

JMais imaginons plutôt que toutes ces fonctions prennent le même argument, par exemple un vecteur d'objets A, A contenant un int pouvant prendre quelques valeurs définies dans une énumération et un void*, et renvoient toutes un objet A.

---

Ca peut être effectivement une solution possible ... que je n'utiliserais pas parce que :

Avantages :
- ça simplifie grandement l'interpreteur
- pas de code ASM à gérer

Mais, Inconvénients :
- tout le code de conversion de type des paramètres va être dupliquer dans toutes les fonctions (passage de vector<A> -> float, float, ...). Donc aucune centralisation, ce qui veux dire, écriture fastidieuse de code un peu partout, d'où risque de bugs lors du "copier-coller-modifier", ...
- de toutes façons c'est pas possible car je n'ai pas la main sur les DLLs à charger (pas de code source), donc impossible de recompiler pour standardiser mes méthodes

Je ne parle absolument pas de recompiler, c'est bien évidemment impossible :)
Il faut savoir utiliser un peu d'astuce. L'interopérabilité avec le C (ou éventuellement C++, mais c'est surtout le C qui est important) est une possibilité dans tous les langages de programmation.
Tous utilisent des wrappers sous une forme ou une autre. Par exemple le Lua utilise un mécanisme très proche de celui que t'ai décrit. Pour appeler une fonction que tu connais, tu crées un wrapper en C qui va récupérer les arguments de type inconnu et en nombre inconnu en provenance du langage de scripting, les décrypter, lancer une erreur si ils ne sont pas bons puis appeler la fonction (que tu connais forcément). Je crois que le python utilise un système à peu près similaire.
Le seul langage à ma connaissance utilisant ce principe est le dotnet. Il permet de définir le prototype d'une fonction en C (nombre d'argument, type, longueur, encodage d'une chaine de caractère,...).
Je te recommanderais plutôt de réfléchir à la première solution, plus réaliste (tu n'es pas Microsoft, tu n'as pas des millions à investir dans un langage :)). Mais rends toi bien compte que ce que tu veux faire est irréalisable tel quel. J'ai l'impression que tu veux laisser la possibilité à tes utilisateurs d'appeler n'importe quelle fonction à n'importe quel moment et n'importe comment, un peu comme on accède à COM en VB. Comment dans ce cas définir le mode de passage d'une chaine de caractères?, le retour par adresse? A moins de créer un langage excessivement proche du C ou du C++ (gestion des pointeurs, taille des types primitifs variable, chaines de caractères "pourries",...) je persiste à dire que ce n'est pas réalisable (et encore).

Citation:

---

Envoyé par zais_ethael

Je ne parle absolument pas de recompiler, c'est bien évidemment impossible :)

---

Ben un peu, si : imposer un framework ou une API que les DLLs doivent respecter, ça implique la recompilation de toutes celles-ci.
Un générateur de wrapper à la SWIG c'est là même chose (mais de l'autre côté).

Citation:

---

L'interopérabilité avec le C (ou éventuellement C++, mais c'est surtout le C qui est important) est une possibilité dans tous les langages de programmation.

---

Justement mon pb. est de rendre mon interpréteur interopérable avec du C.

Citation:

---

Envoyé par zais_ethael

Tous utilisent des wrappers sous une forme ou une autre.

---

Le problème avec le mot wrapper c'est que ça recouvre trop de concepts différents.

Citation:

---

Pour appeler une fonction que tu connais, tu crées un wrapper en C qui va récupérer les arguments de type inconnu et en nombre inconnu en provenance du langage de scripting, les décrypter, lancer une erreur si ils ne sont pas bons puis appeler la fonction (que tu connais forcément). Je crois que le python utilise un système à peu près similaire.

---

Tout le pb. est là : appeller la fonction. On en revient à ma question.

Citation:

---

Le seul langage à ma connaissance utilisant ce principe est le dotnet. Il permet de définir le prototype d'une fonction en C (nombre d'argument, type, longueur, encodage d'une chaine de caractère,...).

---

Tu est déjà allé faire un tour ici :

http://docs.python.org/dev/lib/ctype...continued.html

Et ici ?

http://www.digitalmars.com/d/interfaceToC.html

Citation:

---

Mais rends toi bien compte que ce que tu veux faire est irréalisable tel quel.

---

Bien sur que vouloir prendre en compte toutes les situations possibles, ça tiend de l'utopie ... :sm: ! Mais rassure toi mon usage est trés ciblé. Dans mon cas les bibliothèques dynamiques à charger ne sont pas si en bazarre que ça (au niveau des technologies mises en oeuvre, mais pas du tout au niveau des prototypes). C'est du C en majorité (un peu de C++ pour certaines), pas de redéfinition de types ou de nouvelles structures, les pointeurs et les références ne servent qu'a passer des arguments par adresse, l'allocation se fait toujours dans la DLL, même chose pour la libération mémoire, leur API est trés bien documentée, ...

Ce que je veux juste c'est pouvoir accéder facilement à mes DLLs sans avoir à recompiler mon interpreteur.

Citation:

---

J'ai l'impression que tu veux laisser la possibilité à tes utilisateurs...

---

.

Ne t'inquiètes pas le seul utilisateur ... c'est moi ! J'aurais jamais proposé une solution technique comme ça si c'était professionnel (ça serait aller droit dans le mur :mur:) !

Tu ferais mieux de passer par un langage intermédiaire et un compilateur JIT...

Citation:

---

Envoyé par mchk0123

Ben un peu, si : imposer un framework ou une API que les DLLs doivent respecter, ça implique la recompilation de toutes celles-ci.
Un générateur de wrapper à la SWIG c'est là même chose (mais de l'autre côté).

---

Maiiiiis non. Tu as une dll propriétaire, et bien évidemment les .lib et .h correspondants. Tu crée une biblio C par dessus ça qui ne contient que des fonctions-wrappers (donc d'un prototype fixe) appelant celles de la biblio cible. Tu compiles ton wrapper, tu ne gardes que la dll qui en ressort et voila. Depuis ton espace d'exécution, tu appelles avec les fonctions déja citées la fonction de ton wrapper qui va à son tour appeler celle de la biblio cible. Tu peux même faire un update de la dll propriétaire si ça te chante sans devoir recompiler quoi que ce soit (à condition que le prototype de ses fonctions ne change pas, mais la ça poserait problème dans tous les cas de figure bien évidemment).
Le seul désavantage de cette technique est exactement le même que celui qui apparait en Java. Si ton langage est sensé fonctionner sur plusieurs plateformes avec une sorte de bytecode ou des scripts non-compilés, tu vas devoir compiler le wrapper pour chaque os.

Citation:

---

Envoyé par mchk0123

Tu est déjà allé faire un tour ici :
http://docs.python.org/dev/lib/ctype...continued.html
Et ici ?
http://www.digitalmars.com/d/interfaceToC.html

---

Qu'est-ce que ça prouve? Que python possède en standard un wrapper vers la biblio standard du C? Que le D est un langage d'un fonctionnement similaire au C++ qui permet une compilation combinée avec le C?

Désolé, je ne comprends pas !

C'est quoi un wrapper ?

Regarde ce que me sort wikipedia : http://fr.wikipedia.org/wiki/Wrapper_(informatique)

Ca n'a pas l'air d'être ce que tu dis.

Un wrapper c'est un truc qui enrobe.

La il te sort la définition du design pattern adapter en orienté objet, rien à voir :), ils t'expliquent d'ailleurs qu'un adapter peut être considéré comme un type de wrapper. C'est comme dire que si une table est un meuble tous les meubles sont des tables.
Un wrapper est une couche intermédiaire, généralement destinée à faire la colle entre deux "trucs". Mais quand on parle de faire communiquer deux langages de programmation en général tout le monde comprend, il n'y a pas vraiment de définition.
Tu devrais aller voir comment fonctionne l'intéraction C dans l'un ou l'autre langage de programmation que tu connais (on va naturellement exclure le C++ et le D qui "trichent"). Si tu connais php, python ou encore java ça pourrait être une bonne source d'inspiration.

Bon je déclare définitivement fortait, les DLLs ont l'air d'avoir été compilés avec des options optimisation (en plus peut être différentes) ; ce qui fait que l'ABI n'est pas du tout uniforme.

Pour preuve, en décompilant je m'aperçois que certaines fonctions de la DLL attendent les paramètres via les registres, et d'autres via la pile ... C'est à s'arracher les cheveux.

Merci en tout cas à ceux qui m'ont apporter leurs conseils ; et à ceux aussi, que je n'ai pas crus, quand ils me disaient que je me dirigeais vers une impasse.