Librairie dynamique

Librairie dynamique - question

Bonjour à tous,

J'ai une ou plusieurs questions qui m'ennuie un peu pour les librairies dynamiques.

Voici un header .h e un corps .c:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
#ifndef IOPROTOCOL_H_INCLUDED
#define IOPROTOCOL_H_INCLUDED
 
typedef signed char INT8;
typedef short       INT16;
typedef int         INT32;
typedef unsigned char  UINT8;
typedef unsigned short UINT16;
typedef unsigned int   UINT32;
 
/* Types d'IO */
typedef enum { IOT_U1, IOT_U2, IOT_U8, IOT_I8, IOT_U16, IOT_I16, IOT_U32, IOT_I32, IOT_F32, IOT_STRING, IOT_MAX } IoTypeE;
 
typedef union {
	int  i;
	unsigned int u;
	float  f;
	char * s;
} Value;
 
typedef struct {
	int (*Read) (char *rxbuf, int rxlen, UINT8 interTo);
	int (*Write) (char *txbuf,int txlen);
	int (*FunctionResponse) (int address, Value value, IoTypeE type);
	int (*SendTraceRoute) (char * trace);
} DeviceFuncT;
 
 
    int readTrame( DeviceFuncT *deviceFunct, UINT32 function, UINT32 address, UINT32 countAddress, UINT32 slave, UINT32 type);
    int writeTrame(DeviceFuncT *deviceFunct, UINT32 function, UINT32 address, Value value, UINT32 type, UINT32 slave);
 
 
#endif // IOPROTOCOL_H_INCLUDED

.C que j'ai simplifié ^^.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
#include "IOProtocol.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
 
    int readTrame( DeviceFuncT *deviceFunct,UINT32 function, UINT32 address, UINT32 countAddress, UINT32 slave, UINT32 typeRead){
        char buffer[100];
        sprintf (buffer, "Number function :%d,  Number address :%d, number of address :%d, Number slave :%d, Type de lecture : %d", function,address,countAddress,slave, typeRead);
        deviceFunct->SendTraceRoute(buffer);
 
        return function + address + typeRead;
    }
 
    int writeTrame(DeviceFuncT *deviceFunct, UINT32 function, UINT32 address, Value value, UINT32 type, UINT32 slave){
 
        char temp[100];
        char *v = malloc(sizeof(char) * 500);
        if(type == 7){
            sprintf(v,"%ud",value.u);
        }
        else if(type == 8){
            sprintf(v,"%d",value.i);
        }
        else if(type == 9){
            sprintf(v,"%f",value.f);
        }
        else{
            sprintf(v,"%s",value.s);
        }
 
        sprintf(temp,"Address : %d   Number of function: %d  Value: %s,    NumberType: %d                Number of esclave: %d",address,function,v,type,slave);
        deviceFunct->SendTraceRoute(temp);
        return 1;
    }

Ensuite je compile dans une librairie dynamique dll ou so via la commande :

gcc -Wall -shared a.c -o mydll.dll sous Windows.
gcc -shared a.c -o libmydll.dll sous linux.

Et j'appelle cette libraire dans mon code Java via la bibliothèque JNA.

Je n'ai aucun soucis la-dessus car tout fonctionne ;).

Mes questions sont plûtot parce que je lis partout que pour la création des libraires il faut préciser plein de chose dans le code en C
Comme par exemple :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
BOOL WINAPI DllMain(HINSTANCE hInst, DWORD fdwReason, LPVOID
lpvReserved)
{
switch(fdwReason)
{
case DLL_PROCESS_ATTACH :
// La DLL est chargée dans l’espace de mémoire virtuel
// du processus l’ayant appelé.
// Les routines d’initialisation du DLL peuvent être
// appelées ici.
if(!lpvReserved)
// chargement dynamique
else
// chargement statique
break;
case DLL_THREAD_ATTACH :
// La DLL est déjà chargée par un processus.
// Mais ce processus vient de créer un nouveau « thread ».
// Le point d’entrer « DllMain » est
// alors exécuté dans le contexte de ce nouveau « thread ».
break;
case DLL_PROCESS_DETACH :
// La DLL est déchargée du processus.
// Soit suite à l’appel de
// « FreeLibrary », suite à une erreur de chargement ou
// lors de la fin du processus.
if(!lpvReserved)
// FreeLibrary fut appelée ou le chargement a échoué
else
// le processus s’est terminé
break;
case DLL_THREAD_DETACH :
// Un « thread » du processus ayant chargé la DLL
// se termine.
// Le point d’entrée « DllMain » est alors exécuté dans le
// contexte du « thread » se terminant.
break;
}
return TRUE;
}

A mettre dans le.c

ou encore

Citation:

« __cdecl » : Passage des paramètres sur la pile de droite à gauche. L’appelant est
responsable du nettoyage.
« __stdcall » : Passage des paramètres sur la pile de droite à gauche. L’appelé est
responsable du nettoyage.
« __thiscall » : Convention d’appel pour les fonctions membres (non statique). Passage
des paramètres sur la pile de droite à gauche. L’appelant est responsable
du nettoyage. Un paramètre supplémentaire (pointeur « this ») est passé
dans le registre « %ECX ».

Devant l'en-tête des fonctions...

Alors voilà mes questions, pourquoi ma librairie fonctionne telle alors qu'on me dit que j'ai besoin de cela?

Est-ce que j'en n' ai pas besoin car je suis en C? Oo.

Est-ce que cela fonctionne certes, mais ce n'est pas propre?

Voilà tout ce qui peut m'éclaircir sur la question, je suis prenneur :).

Merci à vous ;).

Réfèrence : 'http://www.cours.polymtl.ca/log2410/docs/documents/dll_theories.pdf'

Si tu ne fais rien dans le DllMain(), tu n'as pas besoin de le mettre.
Pour la convention d'appel, c'est plutôt du côté de JNA qu'il faut voir ça, je dirais: Ça dépend de ce que JNA "attend".

Merci pour ta réponse :).

oui, je me le suis dit un petit peu. Et qu'est ce qu'on peut y mettre? des variables globales initialiser? Ou...?

Sinon le JNA ne demande rien du tout au langage c. Il doit mapper comme il faut le header h. C'est peut-être plus pour JNI... !?

JNI est extrêmement exigeant.
Je ne connais pas JNA, mais il doit y avoir des options indiquant quelle convention d'appel est utilisée par quelle fonction. La même doit être réglée pour les fonctions de la DLL.

PS: Le buffer temp est bcp trop court dans writeTrame(), c'est le dépassement de tampon assuré. Edit: et dans readTrame() aussi, en fait.

Oui, d'après ce que je lis à gauche et droite sur le net il n'y a besoin que de préciser si la fonction est exporté...

Ici cela explique effectivement qu'il n'a pas besoin de faire tout le tchatcha de JNI :

Citation:

The JNA library uses a small native library called foreign function interface library (libffi) to dynamically invoke native code. The JNA library uses native functions allowing code to load a library by name and retrieve a pointer to a function within that library, and uses libffi library to invoke it, all without static bindings, header files, or any compile phase. The developer uses a Java interface to describe functions and structures in the target native library. This makes it quite easy to take advantage of native platform features without incurring the high development overhead of configuring and building JNI code.

Mais sans mettre aucune précision, toutes manipulations possible fonctionnent.

Je suppose qu'il n'est pas difficile de pondre un code qui s'adapte aux deux conventions conventions d'appel __cdecl et __stdcall (du moment que les bons registres sont préservés, notamment EBP) en vérifiant le pointeur de pile à la fin.