Erreur d'execution d'uns dllRésolu

Question

Bonjour tout le monde, voici mon problème : J'ai récupéré un code sur ce fabuleux site qu'est cppfrance;) (http://www.cppfrance.com/codes/BASE-COMMUNICATION-SERIE-RS232-WIN32_22441.aspx) permettant de communiquer avec un port série. J'ai essayé de passer un argument (handle du port COM) en argument (celui-ci était une variable globale) car je souhaiter faire une dll avec les 4 fonctions d'ouverture, écriture, lecture et fermeture du port COM. Et (le problème) ma dll compile correctement, mais lorsque je souhaite m'en servir, je gagne une erreur windows... voici ma dll, en espérant que qqun puisse trouver l'erreur que je ne vois pas. Merci d'avance à tous ceux qui prendront le temps de jeter un coup d'oeil à mon pb. (détails qui peut avoir son importance, ou pas, je travaille avec code::blocks). header : dllFAB_pointeur.h : #ifndef __dllFAB_pointeur_H__ #define __dllFAB_pointeur_H__ #define DllImport __declspec(dllimport) #include DllImport BOOL __stdcall OpenCOM (HANDLE *g_hCOM, int nId); DllImport BOOL __stdcall CloseCOM (HANDLE *g_hCOM); DllImport BOOL __stdcall ReadCOM (HANDLE *g_hCOM, void* buffer, int nBytesToRead, int* pBytesRead); DllImport BOOL __stdcall WriteCOM (HANDLE *g_hCOM, void* buffer, int nBytesToWrite, int* pBytesWritten); #endif source : dllFAB_pointeur.c #include #include #include #include #include "dllFAB_pointeur.h" /* Définition de constantes*/ #define RX_SIZE 4096 /* taille tampon d'entrée */ #define TX_SIZE 4096 /* taille tampon de sortie */ #define MAX_WAIT_READ 5000 /* temps max d'attente pour lecture (en ms) */ #define DllExport __declspec(dllexport) /****************************************************************************** OpenCOM : ouverture et configuration du port COM. entrée : nId : Id du port COM à ouvrir. retour : vrai si l'opération a réussi, faux sinon. ******************************************************************************/ DllExport BOOL __stdcall OpenCOM(HANDLE *g_hCOM, int nId) { /* variables locales */ char szCOM[16]; /* Délais d'attente sur le port COM */ COMMTIMEOUTS g_cto = { MAX_WAIT_READ, /* ReadIntervalTimeOut */ 0, /* ReadTotalTimeOutMultiplier */ MAX_WAIT_READ, /* ReadTotalTimeOutConstant */ 0, /* WriteTotalTimeOutMultiplier */ 0 /* WriteTotalTimeOutConstant */ }; /* Configuration du port COM */ DCB g_dcb = { sizeof(DCB), /* DCBlength */ 9600, /* BaudRate */ TRUE, /* fBinary */ FALSE, /* fParity */ FALSE, /* fOutxCtsFlow */ FALSE, /* fOutxDsrFlow */ DTR_CONTROL_ENABLE, /* fDtrControl */ FALSE, /* fDsrSensitivity */ FALSE, /* fTXContinueOnXoff */ FALSE, /* fOutX */ FALSE, /* fInX */ FALSE, /* fErrorChar */ FALSE, /* fNull */ RTS_CONTROL_ENABLE, /* fRtsControl */ FALSE, /* fAbortOnError */ 0, /* fDummy2 */ 0, /* wReserved */ 0x100, /* XonLim */ 0x100, /* XoffLim */ 8, /* ByteSize */ NOPARITY, /* Parity */ ONESTOPBIT, /* StopBits */ 0x11, /* XonChar */ 0x13, /* XoffChar */ '?', /* ErrorChar */ 0x1A, /* EofChar */ 0x10 /* EvtChar */ }; /* construction du nom du port, tentative d'ouverture */ sprintf(szCOM, "COM%d", nId); *g_hCOM = (HANDLE)CreateFile(szCOM, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_SYSTEM, NULL); if(*g_hCOM == INVALID_HANDLE_VALUE) { printf("Erreur lors de l'ouverture du port COM%d", nId); return FALSE; } /* affectation taille des tampons d'émission et de réception */ SetupComm(*g_hCOM, RX_SIZE, TX_SIZE); /* configuration du port COM */ if(!SetCommTimeouts(*g_hCOM, &g_cto) || !SetCommState(*g_hCOM, &g_dcb)) { printf("Erreur lors de la configuration du port COM%d", nId); CloseHandle(*g_hCOM); return FALSE; } /* on vide les tampons d'émission et de réception, mise à 1 DTR */ PurgeComm(*g_hCOM, PURGE_TXCLEAR|PURGE_RXCLEAR|PURGE_TXABORT|PURGE_RXABORT); EscapeCommFunction(*g_hCOM, SETDTR); return TRUE; } /****************************************************************************** CloseCOM : fermeture du port COM. retour : vrai si l'opération a réussi, faux sinon. ******************************************************************************/ DllExport BOOL __stdcall CloseCOM(HANDLE *g_hCOM) { /* fermeture du port COM */ CloseHandle(*g_hCOM); return TRUE; } /****************************************************************************** ReadCOM : lecture de données sur le port COM. entrée : buffer : buffer où mettre les données lues. nBytesToRead : nombre max d'octets à lire. pBytesRead : variable qui va recevoir le nombre d'octets lus. retour : vrai si l'opération a réussi, faux sinon. ------------------------------------------------------------------------------- Remarques : - la constante MAX_WAIT_READ utilisée dans la structure COMMTIMEOUTS permet de limiter le temps d'attente si aucun caractères n'est présent dans le tampon d'entrée. - la fonction peut donc retourner vrai sans avoir lu de données. ******************************************************************************/ DllExport BOOL __stdcall ReadCOM(HANDLE *g_hCOM, void* buffer, int nBytesToRead, int* pBytesRead) { return ReadFile(*g_hCOM, buffer, nBytesToRead, (DWORD*)pBytesRead, NULL);/*ajout d'un cast*/ } /****************************************************************************** WriteCOM : envoi de données sur le port COM. entrée : buffer : buffer avec les données à envoyer. nBytesToWrite : nombre d'octets à envoyer. pBytesWritten : variable qui va recevoir le nombre d'octets envoyés. retour : vrai si l'opération a réussi, faux sinon. ******************************************************************************/ DllExport BOOL __stdcall WriteCOM(HANDLE *g_hCOM, void* buffer, int nBytesToWrite, int* pBytesWritten) { /* écriture sur le port */ return WriteFile(*g_hCOM, buffer, nBytesToWrite, (DWORD*)pBytesWritten, NULL); } BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle. */ , DWORD reason /* Reason this function is being called. */ , LPVOID reserved /* Not used. */ ) { switch (reason) { case DLL_PROCESS_ATTACH: break; case DLL_PROCESS_DETACH: break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; } /* Returns TRUE on success, FALSE on failure */ return TRUE; }

cs_rt15 · Accepted Answer

Effectivement, le message d'erreur est franchement nul et n'aide pas du tout. Ca sent l'exception ou la runtime. Hou je suis mauvaise langue.

A quoi ressemblent les symboles réclamés par le .exe ?

Z7, Z8... Je sais pas d'où ça sort. Peut être une déco C++. A tout hasard, met des extern "C" dans du ifdef C++ :
#ifdef __cplusplus
#define DllExport  extern "C" __declspec(dllexport)
#else
#define DllExport  __declspec(dllexport)
#endif

Pareil pour DllImport.

cs_rt15 · Answer

Salut,

Utilise dependancy walker (depends) pour analyser ta dll et ton .exe. Il te permet de voir les fonctions importées et exportées par un exécutable, et permet de voir si la résolution est possible.

Travailler ou non avec Code::Blocks est moins important que le compilo que tu utilises. Je suppose que tu utilises gcc + MinGW.

Si les symboles ne sont pas les mêmes entre le .exe et la dll, regarde un coup d'oeil là dessus.

"Un message d'erreur windows". Lequel ? On ne peut pas deviner... Et tu peux toi même tirer des conclusion de ce message d'erreur. Encore que les messages d'erreurs concernant les dll on tendance à induire en erreur (Module introuvable toto.dll, alors que c'est titi.dll utilisée par toto.dll qui est introuvable...).

cs_fabrice91 · Answer

Bonjour rt15 et merci de t'intéresser à mon pb.

En effet j'utilise gcc + MinGW. Le logiciel que tu m'as conseillé (depends) m'a permis de confirmer ce que je pensais : c'est ma dll qui bug : voila les noms des fonctions quand j'ouvre ma dll : 
_Z7OpenCOMPPvi@8
_Z7ReadCOMPPvS_iPi@16
_Z8CloseCOMPPv@4
_Z8WriteCOMPPvS_iPi@16
j'suis assez loin du OpenCOM, ReadCOM, CloseCOM et WriteCOM... Par contre je ne vois pas si la résolution est possible. Il me semble que le problème vient de mon code de la dll.

J'ai également lu le post auquel tu avais répondu et je t'avoue que je n'ai pas tout compris... As tu une idée de l'erreur que je fais à la vue des fonctions que je retrouve dans la dll avec des noms "bizard" ?

Je te rajoute l'erreur que m'affiche windows si elle te parle (perso j'pense que je ne parle pas le windows...) (la dll est appelé par l'executable TESTcom_FAB_dll2.exe :
Erreur de windows : TESTcom_FAB_dll2.exe a rencontré un problème et doit fermer. Nous vous prions de nous excuser pour le désagrément encouru.

Signature de l'erreur : AppName: testcom_fab_dll2.exe     AppVer: 0.0.0.0     ModName: unknown
ModVer: 0.0.0.0     Offset: 00000000

Merci d'avance

cs_fabrice91 · Answer

J'ai rajouté  : #ifdef __cplusplus
#define DllExport  extern "C" __declspec(dllexport)
#else
#define DllExport  __declspec(dllexport)
#endif
 idem
pour l'import

Et maintenant, les noms des fonctions dans la dll sont : 
CloseCOM@4
OpenCOM@8
ReadCOM@16
WriteCOM@16
Ca avance!!!

Par contre je ne vois pas les symboles réclamés par l'exe... Dans depends, lorsque j'ouvre mon exécutable, je n'ai que les dll KERNEL32.dll et MSVCRT.dll et mes fonctions ne sont pas dedans.. Ou voulais tu que je regarde les symboles rclamés par le .exe?

cs_rt15 · Answer

Normalement, ton .exe devrait réclamer ta dll... Tu es sûr que ton exe utilise des fonctions de la dll ? Depends ne détecte cependant pas que ta dll est nécessaire si tu es lié dynamiquement à ta dll (LoadLibrary).

Pour virer les @n...

J'ai pas essayé, alors tu me tiens au courant !

Project->Build options->Linker Settings

Dans "other linker options", tu met :
--kill-at

Pourquoi ?

cs_fabrice91 · Answer

En effet, celle-ci est liée dynamiquement. Ceci explique donc cela...
Concernant les @n, j'ai rajouté --kill-at et puis 
--add-stdcall-alias pour voir la différence, mais cela n'a pas donné grand chose... voire rien du tout.

cs_rt15 · Answer

Après essai, il faut utiliser :
-Wl,--kill-at

C'est zarbi car on pourrait penser que l'argument est passé directement au lieur, mais non, donc il faut bien utiliser Wl.

cs_fabrice91 · Answer

Merci beaucoup rt15 pour ton aide,  cela fonctionne parfaitement et du coup mon exe fonctionne lui aussi!! Penses tu que cela aurait fonctionné si les fonctions appelées dans l'exe étaient syntaxiquement identiques (genre OpenCOM@4 si je n'avais pas rajouté les options de compilation : -Wl,--kill-at) ? Et ensuite sais tu (par curiosité) à quoi correspondait le numéro après le @? Si tu n'as pas la réponse, ne te prends pas la tête, tu as deja fait bcp pour moi, encore merci  et merci, bonne continuation!

cs_rt15 · Answer

Cela aurait très certainement fonctionné si tu avais mis les @nn dans les GetProcAddress.

Mais bon, c'est quand même plus pratique et esthétique que le symbole corresponde au nom de la fonction.

Le nn de @nn correspond à la taille des arguments passés à la fonction, en octet.

Par exemple :
BOOL __stdcall OpenCOM (HANDLE *g_hCOM, int nId);

Deux arguments de type HANDLE et int, qui font tous les deux 4 octets -> OpenCOM@8.

Lors d'un appel de fonction, les arguments sont empilés (push) sur la pile :
push valeur pour g_hCOM
push valeur pour nId
call OpenCOM
Instruction après l'appel

La tête de la pile s'est donc déplacée de 8 octets.

A la fin de la fonction, il faut dépiler les arguments pour que la pile revienne à sa position initiale.

Avec la convention __stdcall, c'est la fonction appelée qui a ce rôle :

OpenCOM
Instructions de OpenCOM
ret 8

ret 8 fait revenir à l'exécution de l'appelante et fait un dépilement (pop) de 8 octets.

Avec la convention __cdecl, c'est l'appelante qui a ce rôle :

push valeur pour g_hCOM
push valeur pour nId
call OpenCOM
pop de 8 octets. En fait ajustement de esp qui pointe sur la tête de la pile : add esp, 8 (La pile croit suivant les adresses décroissantes).
Instruction après l'appel

Avec une instruction en plus, la convention __cdecl est donc moins performante que la __stdcall.

cs_fabrice91 · Answer

Merci encore pour ta réponse, mais je vois pas ce que sont les GetProcAddress (dsl de mon ignorance...)

Ensuite pour la différence de performance entre la convention __cdecl et __stdcall, si je comprends bien pour la première c'est la fonction appelante (donc mon .exe) qui dépile les arguments avec l'instruction :  add esp, 8
et pour la seconde c'est la fonction OpenCOM qui dépile les arguments avec l'instruction : ret 8 qu'elle envoie après avoir envoyé ses instructions. mais qd empile t elle ses arguments sur la pile? (si les instructions sont : OpenCOM
Instructions de OpenCOM
ret 8)

cs_rt15 · Answer

Bin si tu es lié dynamiquement à ta dll tu utilises LoadLibrary pour la charger et GetProcAddress pour trouver les adresses des fonctions, non ? C'est forcément le .exe qui empile, vu que c'est lui qui a les arguments. (D'ailleurs erratum, les arguments sont poussés de droite à gauche, donc nId en premier). __stdcall

EXE : push valeur pour nId push valeur pour g_hCOM call OpenCOM Instruction après l'appel DLL : OpenCOM Instructions de OpenCOM ret 8

__cdecl

EXE : push valeur pour nId push valeur pour g_hCOM call OpenCOM add esp, 8 Instruction après l'appel DLL : OpenCOM Instructions de OpenCOM ret

cs_fabrice91 · Answer

Au temps pour moi, j'ai répondu trop vite, j'utilise bien GetProcAddress... 
Merci pour le détail, je comprends bcp mieux le fonctionnement des 2 conventions! Je pense que j'arrive au bout des questions que je me posait sur ce sujet, je vais te laisser tranquille un peu  , encore merci et bonne continuation!

Erreur d'execution d'uns dll

12 réponses

Votre réponse

Discussions similaires