Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Frédéric Lachasse
"hackervalley" wrote in message news:408058da$0$493$
Voila , j'essaye de faire un wrapper de dlopen. Je bloque sur dlsym, car je n'arrive pas à avoir l'adresse du symbol. Mon code donne ceci : [Code coupé car non-important]
Le post est un peu hors-sujet, car C++ n'a pas la notion de DLL/dydnamic linked libraries/shared libraries/shared objects. Mais le problème est classique et la solution fait partie du langage C++.
Le problème: la décoration de nom ou "name mangling". C++ permet d'"overloader" les fonctions, c'est-à-dire permet d'avoir des fonctions ayant le même nom à condition que leurs signatures (types et nombres d'arguments) soient différentes. Par exemple:
int mod(int a, int b); // modulo de 2 entiers int mod(double a, double b); // modulo de 2 réels
Cela veut dire que dans une DLL, les deux fonctions doivent avoir des nom différents. Pour cela, le compilateur C++ "décore" (mangle) le nom de la fonction en ajoutant un codage en fonction des arguments (et parfois du type de retour). Par exemple:
mod__II_I (fonction mod avec 2 int retournant un int) mod__DD_I (function mod avec 2 double retournant un int)
Cette décoration est totalement dépendante du compilateur (cela explique que les compilateurs C++ sont rarement compatible entre eux). Pour trouver le symbole dans une DLL, il faut utiliser le nom décoré. Ce qui est plutôt pénible, le système de décoration étant souvant compliqué et rarement documenté.
Par contre, il y a un moyen de dire au compilateur de ne pas décorer une fonction. Cela permet au compilateur C++ d'appeler des fonctions générées par un compilateur C (qui ne sont pas décorées) ou de faire des fonctions appelables par un programme C (qui ne sait pas décorer). Ce moyen est la déclaration extern "C".
// Déclaration d'une fonction dont le nom ne sera pas décoré: extern "C" void vInitModules1(void);
// Si on définit la fonction plus loin, il n'est pas nécessaire // de répéter extern "C" void vInitModules1() { //... }
Ainsi, il sera beaucoup plus facile de trouver la fonction avec dlsym dans la DLL.
-- Frédéric Lachasse - ECP86
"hackervalley" <hackervalley@free.fr> wrote in message
news:408058da$0$493$636a15ce@news.free.fr...
Voila , j'essaye de faire un wrapper de dlopen.
Je bloque sur dlsym, car je n'arrive pas à avoir l'adresse du symbol.
Mon code donne ceci :
[Code coupé car non-important]
Le post est un peu hors-sujet, car C++ n'a pas la notion de DLL/dydnamic
linked libraries/shared libraries/shared objects. Mais le problème est
classique et la solution fait partie du langage C++.
Le problème: la décoration de nom ou "name mangling". C++ permet
d'"overloader" les fonctions, c'est-à-dire permet d'avoir des fonctions
ayant le même nom à condition que leurs signatures (types et nombres
d'arguments) soient différentes. Par exemple:
int mod(int a, int b); // modulo de 2 entiers
int mod(double a, double b); // modulo de 2 réels
Cela veut dire que dans une DLL, les deux fonctions doivent avoir des nom
différents. Pour cela, le compilateur C++ "décore" (mangle) le nom de la
fonction en ajoutant un codage en fonction des arguments (et parfois du type
de retour). Par exemple:
mod__II_I (fonction mod avec 2 int retournant un int)
mod__DD_I (function mod avec 2 double retournant un int)
Cette décoration est totalement dépendante du compilateur (cela explique que
les compilateurs C++ sont rarement compatible entre eux). Pour trouver le
symbole dans une DLL, il faut utiliser le nom décoré. Ce qui est plutôt
pénible, le système de décoration étant souvant compliqué et rarement
documenté.
Par contre, il y a un moyen de dire au compilateur de ne pas décorer une
fonction. Cela permet au compilateur C++ d'appeler des fonctions générées
par un compilateur C (qui ne sont pas décorées) ou de faire des fonctions
appelables par un programme C (qui ne sait pas décorer). Ce moyen est la
déclaration extern "C".
// Déclaration d'une fonction dont le nom ne sera pas décoré:
extern "C" void vInitModules1(void);
// Si on définit la fonction plus loin, il n'est pas nécessaire
// de répéter extern "C"
void vInitModules1()
{
//...
}
Ainsi, il sera beaucoup plus facile de trouver la fonction avec dlsym dans
la DLL.
"hackervalley" wrote in message news:408058da$0$493$
Voila , j'essaye de faire un wrapper de dlopen. Je bloque sur dlsym, car je n'arrive pas à avoir l'adresse du symbol. Mon code donne ceci : [Code coupé car non-important]
Le post est un peu hors-sujet, car C++ n'a pas la notion de DLL/dydnamic linked libraries/shared libraries/shared objects. Mais le problème est classique et la solution fait partie du langage C++.
Le problème: la décoration de nom ou "name mangling". C++ permet d'"overloader" les fonctions, c'est-à-dire permet d'avoir des fonctions ayant le même nom à condition que leurs signatures (types et nombres d'arguments) soient différentes. Par exemple:
int mod(int a, int b); // modulo de 2 entiers int mod(double a, double b); // modulo de 2 réels
Cela veut dire que dans une DLL, les deux fonctions doivent avoir des nom différents. Pour cela, le compilateur C++ "décore" (mangle) le nom de la fonction en ajoutant un codage en fonction des arguments (et parfois du type de retour). Par exemple:
mod__II_I (fonction mod avec 2 int retournant un int) mod__DD_I (function mod avec 2 double retournant un int)
Cette décoration est totalement dépendante du compilateur (cela explique que les compilateurs C++ sont rarement compatible entre eux). Pour trouver le symbole dans une DLL, il faut utiliser le nom décoré. Ce qui est plutôt pénible, le système de décoration étant souvant compliqué et rarement documenté.
Par contre, il y a un moyen de dire au compilateur de ne pas décorer une fonction. Cela permet au compilateur C++ d'appeler des fonctions générées par un compilateur C (qui ne sont pas décorées) ou de faire des fonctions appelables par un programme C (qui ne sait pas décorer). Ce moyen est la déclaration extern "C".
// Déclaration d'une fonction dont le nom ne sera pas décoré: extern "C" void vInitModules1(void);
// Si on définit la fonction plus loin, il n'est pas nécessaire // de répéter extern "C" void vInitModules1() { //... }
Ainsi, il sera beaucoup plus facile de trouver la fonction avec dlsym dans la DLL.
-- Frédéric Lachasse - ECP86
Jean-Marc Bourguet
"Frédéric Lachasse" writes:
Cette décoration est totalement dépendante du compilateur (cela explique que les compilateurs C++ sont rarement compatible entre eux).
Voir la FAQ, question 7.1 et 7.2, ta description renverse un peu la dépendance (la situation est plutôt que les compilateurs sont rarement compatibles et qu'on s'assure que le problème est détecté aussi rapidement que possible en utilisant des décorations différentes).
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Cette décoration est totalement dépendante du compilateur (cela explique que
les compilateurs C++ sont rarement compatible entre eux).
Voir la FAQ, question 7.1 et 7.2, ta description renverse un peu la
dépendance (la situation est plutôt que les compilateurs sont rarement
compatibles et qu'on s'assure que le problème est détecté aussi
rapidement que possible en utilisant des décorations différentes).
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Cette décoration est totalement dépendante du compilateur (cela explique que les compilateurs C++ sont rarement compatible entre eux).
Voir la FAQ, question 7.1 et 7.2, ta description renverse un peu la dépendance (la situation est plutôt que les compilateurs sont rarement compatibles et qu'on s'assure que le problème est détecté aussi rapidement que possible en utilisant des décorations différentes).
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org