Discussion :

[Zillon]

Bonjour,

Je me pose certaines questions à propos de l'option --wrap du linker gnu permettant de créer automatiquement un alias sur un certain symbole.

Code :

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

1
2
--wrap symbol
    Use a wrapper function for symbol. Any undefined reference to symbol will be resolved to __wrap_symbol. Any undefined reference to __real_symbol will be resolved to symbol. This can be used to provide a wrapper for a system function. The wrapper function should be called __wrap_symbol. If it wishes to call the system function, it should call __real_symbol

J'ai tout d'abord essayé cette option comme indiqué dans l'exemple. A savoir, j'ai écrit le code suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
//essaiWrap.c
#include "malloc_wrapper.h"
 
int main(void)
{
  int* a = (int *) malloc(sizeof(int));
  *a = 3;
  printf("a = %i", *a);
  free(a);
}

Code :

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

1
2
3
//malloc_wrapper.h
#include <stdlib.h>
void * __wrap_malloc(size_t c);

Code :

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

1
2
3
4
5
6
7
8
9
 
//malloc_wrapper.c
#include "malloc_wrapper.h"
 
void * __wrap_malloc(size_t c)
{
  printf ("malloc called with %i\n", c);
  return ((void*)__real_malloc(c));
}

Je compile ce code avec le makefile suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
all : essaiWrap
 
essaiWrap : essaiWrap.o malloc_wrapper.o
	mingw32-gcc.exe -o essaiWrap.exe -Wl,--wrap,malloc essaiWrap.o malloc_wrapper.o
 
malloc_wrapper.o : malloc_wrapper.c
	mingw32-gcc.exe -c -I. malloc_wrapper.c
 
essaiWrap.o : essaiWrap.c
	mingw32-gcc.exe -c -I. essaiWrap.c

la compilation se passe bien, mais à l'execution j'ai :

malloc called with 60
malloc called with 4
a = 3

Première question : d'où vient le premier malloc?

Ensuite, j'essaye de mettre la définition du __wrap_malloc dans une librarie.
malloc_wrapper.c devient donc :

Code :

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

1
2
3
4
5
6
7
8
9
 
//malloc_wrapper.c
#include "malloc_wrapper.h"
 
void * __wrap_malloc(size_t c)
{
  printf ("malloc called with %i\n", c);
  return ((void*)malloc(c)); //plus d'appel à __real_malloc car la librarie sera créee sans l'option --wrap
}

Le reste du code est identique, seulement le makefile est maintenant le suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
all : essaiWrap
 
essaiWrap : essaiWrap.o libmalloc_wrapper.a
	mingw32-gcc.exe -o essaiWrap.exe -Wl,--wrap,malloc -L. -lmalloc_wrapper essaiWrap.c
 
libmalloc_wrapper.a : malloc_wrapper.o
	ar -cru ./libmalloc_wrapper.a malloc_wrapper.o
 
malloc_wrapper.o : malloc_wrapper.c
	mingw32-gcc.exe -c -I. malloc_wrapper.c

Avec ce makefile, je ne peux plus compiler (le compilateur me dit que le symbole __wrap_malloc n'est pas défini...). Quelqu'un voit-il d'où vient le problème?

Enfin dernière question, j'ai fait quelques recherches mais je n'ai pas trouvé d'équivalent à cette option sur le linker du compilo visual. Est ce qu'il n'y en a effectivement pas? Si c'est le cas quelqu'un sait-il à quoi celà est-il du?

Merci de m'avoir lu,

Zillon

[D[r]eadLock]

Première question : d'où vient le premier malloc?

À mon avis de l'initialisation de ton programme qui a besoin d'un peu de mémoire et qui fait un malloc. Et, du fait que ce soit TON malloc qui soit appelé tu le vois ! En désassemblant tu devrais trouver...

Avec ce makefile, je ne peux plus compiler (le compilateur me dit que le symbole __wrap_malloc n'est pas défini...). Quelqu'un voit-il d'où vient le problème?

Non, mais c'est au link de ton .exe que le 'compilo' te sors ce message d'erreur ?
C'est normal d'avoir un .c pour le .exe (et pas un .o) ?

[Zillon]

À mon avis de l'initialisation de ton programme qui a besoin d'un peu de mémoire et qui fait un malloc. Et, du fait que ce soit TON malloc qui soit appelé tu le vois ! En désassemblant tu devrais trouver...

C'est possible, mais ça me semble un petit peu douteux qu'un malloc soit rajouté spontanément au programme pour l'initialisation... Cependant, j'ai refait un essai en wrappant realloc au lieu de malloc, mon programme devenant :

Code :

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

1
2
3
4
5
6
7
8
9
10
#include "malloc_wrapper.h"
 
int main(void)
{
  int* a = (int *) malloc(sizeof(int));
  realloc(a, sizeof(int));
  *a = 3;
  printf("a = %i", *a);
  free(a);
}

Et il n'y a bien qu'un seul appel à realloc. Je suppose que c'est donc bien le cas, un malloc est fait pour je ne sais quelle raison, et il est lui aussi wrappé.
(Le désassembleur m'a donné un retour un peu laborieux à étudier, je ne me suis pas attardé dessus)

Non, mais c'est au link de ton .exe que le 'compilo' te sors ce message d'erreur ?
C'est normal d'avoir un .c pour le .exe (et pas un .o) ?

Oui, c'est au link que j'ai ce message d'erreur. Et non, ce n'est pas normal d'avoir un c au lieu d'un o Mais en l'occurence ça ne posait pas de problème, l'erreur ne venait pas de celà...

Merci en tout cas de t'intéresser au problème

[D[r]eadLock]

Hum, plusieurs idées:
- as-tu essayé avec __real_malloc() dans __wrap_malloc (pour la version lib), parce que c'est peut-être un 'remplacement' à run-time, du coup to malloc() dans ton wrapper.
- as-tu regardé où dans tes objects tu as un appel à __wrap_malloc.
- essaie peut-être de définir qqchose d'autre dans ta lib, pour voir si ta lib est bien inclue.
- as-tu le meme message sans le -L. -lwrap_malloc ?
- ta librairies 'exporte'-t-elle bien __wrap_malloc ?

[Zillon]

- as-tu essayé avec __real_malloc() dans __wrap_malloc (pour la version lib), parce que c'est peut-être un 'remplacement' à run-time, du coup to malloc() dans ton wrapper.

Le wrap ne se fait qu'au linkage de mon exécutable, la librairie est déjà crée et n'est pas modifiée. J'ai quand même essayé par acquis de conscience, c'est bien le cas. La librairie doit bien faire appel à malloc et pas à __real_malloc

- as-tu regardé où dans tes objects tu as un appel à __wrap_malloc.

Je ne comprends pas ce que tu veux dire, peux tu préciser stp?

- essaie peut-être de définir qqchose d'autre dans ta lib, pour voir si ta lib est bien inclue.

Il semble effectivement qu'il y ait un problème, si je définit une autre fonction dans ma lib, elle n'est pas reconnue non plus...

- as-tu le meme message sans le -L. -lwrap_malloc ?

Oui, mais d'un autre côté, si j'écris -lwrap_maaaalloc, j'ai une erreur comme quoi libwrap_maaaalloc.a n'a pas été trouvé, donc à priori ma librairie est bien chargée..

- ta librairies 'exporte'-t-elle bien __wrap_malloc ?

Dans mon idée les symboles étaient forcément exportés lorsqu'on crée une librarie statique... Seulement je viens de faire un test en enlevant tout ce qui parle de l'option wrap, juste en créant une librairie qui défini une fonction bidon et un programme qui se link à cette lib et j'ai le même problème de symbole non défini...
Je vais chercher de ce côté là, merci pour le coup de main

[Zillon]

Grace à tes pistes je viens de comprendre l'erreur que j'ai faite:
j'ai simplement oublié la règle qui dit que l'on doit d'abord passer au linker l'objet qui référence un symbole puis la librairie qui définit ce symbole.

J'ai donc changé la ligne de mon makefile:

Code :

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

mingw32-gcc.exe -o essaiWrap.exe -Wl,--wrap,malloc -L. -lmalloc_wrapper essaiWrap.o

en

Code :

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

mingw32-gcc.exe -o essaiWrap.exe -Wl,--wrap,malloc  essaiWrap.o -L. -lmalloc_wrapper

Sinon, à tout hasard, ne connaitrais tu pas un équivalent à l'option -wrap pour le linker de visual?^^

[D[r]eadLock]

Pas mal. Je ne savais pas qu'il y avait une règle pour les libs, mais c'est vrai qu'on les mets toujours à la fin. Il y avait bien une raison .

Pour "regarde[r] dans les objets les appels à __wrap_malloc", c'était utiliser objdump pour voir les réallocations que le linker devrait faire (si c'est possible).

Pour le "-L. -lwrap_malloc", c'était sans les deux, pour voir si tu avais exactement le même message d'erreur (ce qui aurait été oui).

Quant à visual, euh, j'en ai aucune idée (et ne suis pas sur que ce soit possible); je n'utilise que gcc et ne connaissais pas cette "extension".