exécution de "blocs" d'instruction créés dynamiquement

Salut,


J'ai un léger problème pour réussir à exécuter des blocks d'instructions que j'ai créé dynamiquement

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

void blockExecute() { size_t size = &&block_end - &&block_begin; void* buf = malloc(size); if (buf == NULL) { puts("allocation du buffer impossible"); fflush(stdout); exit(-1); } void* block = memcpy(buf, &&block_begin, size);   puts("début de l'exécution"); fflush(stdout); goto *block;   block_begin: puts("coucou"); block_end: return;   }   int main(int argc, char** argv) { blockExecute(); return 0; }

---

et ça me sort ceci :

Citation:

---

gorgonite@GorgonMobile$ make BasicBlocks.exe
gcc -O0 -Wall BasicBlocks.c -o BasicBlocks.exe
gorgonite@GorgonMobile$ ./BasicBlocks.exe
début de l'exécution
Erreur de segmentation (core dumped)

---

si quelqu'un voit comment s'y prendre... ça m'intéresserait ;)

Je te conseille de rajouter quelques printf histoire de vérifier si les adresses que tu souhaites utiliser et donc la taille de mémoire que tu souhaites allouer sont corrects.
De plus je me demande si tu ne devrais pas faire :

Code:

---

void* buf = malloc(size+1); // au lieu de size seuleument

---

Bon courage ;)

Je crois que c'est dû au fait que les pages mémoires ont des droits spécifiques. Par exemple, tu ne peux exécuter que les pages qui ont le droit d'exécution (le segment CODE). Là, tu essayes d'exécuter dans le tas, et on a pas le droit.
Ceci dépend des systèmes.


De plus, le retour ne doit pas très bien se faire. Tu fais puts, et après, ça part en vrille car il n'y a pas de retour. Tu as essayé d'utiliser GDB pour voir d'où venait l'erreur exactement ?

Citation:

---

Envoyé par millie

Je crois que c'est dû au fait que les pages mémoires ont des droits spécifiques. Par exemple, tu ne peux exécuter que les pages qui ont le droit d'exécution (le segment CODE). Là, tu essayes d'exécuter dans le tas, et on a pas le droit.
Ceci dépend des systèmes.

---

justement sur les x86, cette sécurité n'est pas implantée.... car le controle en exécution des pages mémoire ne se fait pas au même niveau que sur les autres architectures ; c'est entre autre pour cela que les shell code sont redoutables ;)
(enfin, si j'ai bien compris :?)

Citation:

---

Envoyé par millie

De plus, le retour ne doit pas très bien se faire. Tu fais puts, et après, ça part en vrille car il n'y a pas de retour. Tu as essayé d'utiliser GDB pour voir d'où venait l'erreur exactement ?

---

ben je mets le retour...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

void blockExecute() { size_t size = &&block_end - &&block_begin; void* buf = malloc(size+1); if (buf == NULL) { puts("allocation du buffer impossible"); fflush(stdout); exit(-1); } void* block = memcpy(buf, &&block_begin, size); printf("adresse du bloc %p\tlongueur %d\n",&&block_begin,(int) size); printf("adresse du buffer %p\n",block);   puts("début de l'exécution"); fflush(stdout); goto *block;   block_begin: puts("coucou"); return; block_end: return;   }

---

au passage, j'ai fait les printf conseillés par TheGzD ;)

Citation:

---

gorgonite@GorgonMobile$ ./BasicBlocks.exe
adresse du bloc 0x804855c longueur 14
adresse du buffer 0x804a430
début de l'exécution
Erreur de segmentation (core dumped)

---

J'ai un peu plus regardé, histoire de voir si les bonnes zones étaient bien copiées.

J'ai également fait tourner le programme sur un SPARC, j'ai également l'erreur de segmentation. Je pense qu'il y a tout de même une protection sur l'exécution de page virtuelle qui se trouve dans le tas, même sous x86.


Voilà le dernier code modifié :

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 42 43 44 45 46 47

#include <stdio.h> #include <stdlib.h> #include <signal.h>   void handler(int i) { fprintf(stderr, "Oula, je n'ai pas segfaulté\n"); }   void blockExecute() { ssize_t size = &&block_end - &&block_begin; fprintf(stderr, "Size : %d\n", (int) size); void* buf = malloc(size); if (buf == NULL) { puts("allocation du buffer impossible"); fflush(stdout); exit(-1); }     void* block = memcpy(buf, &&block_begin, size);   char * chaine = block; char * chaineA = &&block_begin; fprintf(stderr," Chaine : %10s\n", chaine); fprintf(stderr," Chaine A : %10s\n", chaineA); void * blockNormal = &&block_begin;   fprintf(stderr, "début de l'exécution"); goto *buf;   return; block_begin: fprintf(stderr, "Ici"); goto block_end; block_end: return; }   int main(void) { signal(SIGSEGV, handler); blockExecute(); return 0; }

---

Au passage, je te conseille d'utiliser fprintf(stderr, ""); au lieu de printf (stderr n'est pas bufferisé)

perso, quand je laisse les puts, je me prends une infinité de

Citation:

---

Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté
Oula, je n'ai pas segfaulté

---

et je retombe sur le même message d'erreur quand je passe tout en fprintf(stderr,...)

et toi ?

T'as vu, il n'a pas seg faulté :mouarf:

Sous linux, j'ai pareil (ce qui est normal, il doit chercher à exécuter, il dit qu'il peut pas, mais il avance, et donc ça boucle comme ça).

Sous Windows, le programme se finit quand même pas un signal que je n'ai pas déterminé (il affiche tout de même un : Oula je n'ai pas segfaulté avant de finir)

Sous Solaris/Sparc, j'ai :

Code:

---

1 2	Oula, je n'ai pas segfaulté Segmentation Fault (core dumped)

---

Ce qui est ultra bizarre... A moins qu'il y ait un autre signal qui n'est pas SIGSEGV et qui affiche ça...

Meme sans protection, il y a pas mal de chance que le compilateur utilise des sauts relatifs plutot que des sauts absolus comme tu l'esperes, sans parler des effets des optimiseurs.

Quel est le probleme que tu essaies de resoudre?

(gnu lightening? je ne sais pas dans quel etat c'est)

Citation:

---

Envoyé par Jean-Marc.Bourguet

Meme sans protection, il y a pas mal de chance que le compilateur utilise des sauts relatifs plutot que des sauts absolus comme tu l'esperes, sans parler des effets des optimiseurs.

---

je suis sans optimisation pour le moment -O0 ;)

Citation:

---

Envoyé par Jean-Marc.Bourguet

Quel est le probleme que tu essaies de resoudre?

---

je veux pouvoir générer dynamiquement des blocs de code, et les exécuter... c'est tout :)

Citation:

---

Envoyé par Jean-Marc.Bourguet

(gnu lightening? je ne sais pas dans quel etat c'est)

---

je ne connaissais pas GNU lightening... merci :)

mais ça ne s'applique pas à mon problème... on veut absolument se passer de JIT, pour minimiser la consommation mémoire de la vm ;)

Citation:

---

Envoyé par gorgonite

je suis sans optimisation pour le moment -O0 ;)

---

Les sauts relatifs doivent quand meme etre la.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

(gdb) x/20i buf 0x94ef008: sub $0x8,%esp 0x94ef00b: push $0x804876f 0x94ef010: pushl 0x8049894 0x94ef016: call 0x94eedd8 0x94ef01b: add $0x10,%esp 0x94ef01e: add %al,(%eax) 0x94ef020: add %al,(%eax) 0x94ef022: add %al,(%eax) 0x94ef024: loope 0x94ef035 0x94ef026: add (%eax),%al 0x94ef028: add %al,(%eax) 0x94ef02a: add %al,(%eax) 0x94ef02c: add %al,(%eax) 0x94ef02e: add %al,(%eax) 0x94ef030: add %al,(%eax)

---

Citation:

---

je veux pouvoir générer dynamiquement des blocs de code, et les exécuter... c'est tout :) (enfin je peux donner plus de détails, mais si je réussis mon coup, je pourrais publier un papier pour VEE)

---

Tu te fais un tableau de labels sur lequel tu as un pointeur (current), tu commences par

Code:

---

goto *current++;

---

et tes blocs se terminent par la meme chose.

Bonjour,

le problème est relativement simple, c'est tout simplement parce que un bloc de code relogeable ne doit pas appeler une fonction statique.

Le code en tant que tel fonctionne très bien (le code entre "block_begin" et "block_end") est bien copié, et on à bien un saut vers la mémoire alloué.

Code:

---

1 2 3 4

block_begin: puts("coucou"); block_end: return;

---

Désassemblage du bloc de code dans le programme :

Code:

---

1 2 3 4 5 6 7 8

00401370 MOV DWORD PTR SS:[ESP],Test.0040304B ; ASCII "coucou" 00401377 CALL <JMP.puts> ; puts (CALL 0x401A20) 0040137C ADD ESP,10 ; nettoyage du stack frame 0040137F POP EBX 00401380 POP ESI 00401381 LEAVE ; quitte le stack frame 00401382 RETN ; retour

---

Notez qu'ici, la fonction PUTS est appelée via son import en statique dans le programme. Dans mon cas un CALL 0x401A20

Le même code dans le tas (heap) alloué par malloc :

Code:

---

1 2 3 4 5 6 7 8

003D3CA8 MOV DWORD PTR SS:[ESP],40304B ; ASCII "coucou" 003D3CAF CALL 003D4358 ; ne correspond à rien du tout ! 003D3CB4 ADD ESP,10 003D3CB7 POP EBX 003D3CB8 POP ESI 003D3CB9 LEAVE 003D3CBA RETN

---

Ici le CALL (appelle de fonction / procédure) ne correspond à rien du tout.

Le CALL sous x86 sont encodé avec un déplacement. Si on prend le CALL vers puts dans le programme (ici avec ses opcodes) :

Adresse de l'instruction : 0x401377
Opocde de CALL : 0xE8
Déplacement (little endian) : 0x06A4

Code:

---

1 2	00401377 E8 A4060000 CALL <JMP.puts> ; puts

---

Adresse du CALL + déplacement + taille instruction :

0x401377 + 06A4 + 5 : 0x401A20 (soit l'adresse où est importée la fonction puts)

Le CALL dans le tas est encodé de la même façon, puisque le memcopy() ne fait que copier les opcodes :

Code:

---

1 2	003D3CAF E8 A4060000 CALL 003D4358

---

Seulement ici l'adresse 0x3D4358 ne correspond à rien du tout :!: Donc pour que ce type de code fonctionne il faut aussi recalculer le déplacement nécessaire au CALL...

Citation:

---

Envoyé par Jean-Marc.Bourguet

Tu te fais un tableau de labels sur lequel tu as un pointeur (current), tu commences par

Code:

---

goto *current++;

---

et tes blocs se terminent par la meme chose.

---

déjà fait... c'est une optimisation classique (de Ricardi si je ne me trompe pas), et je cherche à optimiser un peu plus ;)

j'ai changé le code de mon bloc pour tester sans appels de méthodes...

Code:

---

1 2 3 4 5 6 7

block_begin: { // fprintf(stderr,"coucou\n"); int i = 2; i *= 3; return i; } block_end: return 0;

---

et je me prends toujours ceci :

Citation:

---

gorgonite@GorgonMobile$ ./BasicBlocks.exe
adresse du bloc 0x8048558 longueur 28
adresse du buffer 0x804a008
début de l'exécution
Erreur de segmentation (core dumped)

---

Citation:

---

Envoyé par gorgonite

J'ai un léger problème pour réussir à exécuter des blocks d'instructions que j'ai créé dynamiquement

---

Il n'y a aucun moyen portable de faire ce que tu veux.

• Rien ne dit que des étiquettes de goto aient des adresses valides
• Tu copies du code en mémoire de données. Rien ne dit que cette mémoire ait les droits d'exécution, ni que ces adresses (code) soient valides dans l'espace traité par la copie (données)...

Bref, le comportement est indéterminé.

Que veux-tu faire exactement ? Peut être que la méthode n'est pas la bonne...

Citation:

---

Envoyé par gorgonite

déjà fait... c'est une optimisation classique (de Ricardi si je ne me trompe pas), et je cherche à optimiser un peu plus ;)

---

J'ai tendance a mettre ca en rapport avec les implementations de Forth. Tiens une page sur le sujet http://www.complang.tuwien.ac.at/for...aded-code.html a l'air de l'attribuer (ou des variantes proches) a Charles Moore en 1970. R.K. Dewar a employe des techniques semblables pour SPITBOL.

Citation:

---

Envoyé par gorgonite

j'ai changé le code de mon bloc pour tester sans appels de méthodes...

Code:

---

1 2 3 4 5 6 7

block_begin: { // fprintf(stderr,"coucou\n"); int i = 2; i *= 3; return i; } block_end: return 0;

---

et je me prends toujours ceci :

---

Par contre ici, ça ne m'étonne pas. Quand tu déclares int i ici, en fait lors de la compilation, l'espace peut être réservé une fois pour toute dans toute la fonction au niveau de la pile (il y a des implémentations différentes qui ne nécessite pas de pile, mais je parle dans un cas assez "général").

Ce qui fait que de toute façon, les données seront totalement incohérentes, si par exemple tu appelles ton code crée dynamiquement dans une autre fonction, alors la variable ne sera pas au bon endroit dans la pile (car pas vraiment déclaré)

De plus, le return i fait pas mal de chose (comme dépiler les arguments, dépiler l'adresse de retour (au moment de l'appel) et revenir dessus. Et il y a de forte chance que ça ne marche pas.

Citation:

---

Envoyé par gorgonite

j'ai changé le code de mon bloc pour tester sans appels de méthodes...

Code:

---

1 2 3 4 5 6 7

block_begin: { // fprintf(stderr,"coucou\n"); int i = 2; i *= 3; return i; } block_end: return 0;

---

et je me prends toujours ceci :

---

Je te suggere de regarder l'assembleur (gcc -S). gcc implemente les return par des sauts a l'epilogue. Et vu que ces sauts sont relatifs, ca ne va jamais marcher par copie.

Citation:

---

Envoyé par Emmanuel Delahaye

Que veux-tu faire exactement ? Peut être que la méthode n'est pas la bonne...

---

je veux passer à l'étape de preparation sequences en suivant le modèle décrit dans le papier de Gagnon & Hendren http://www.sable.mcgill.ca/publicati...per-2003-2.pdf

la création et l'exécution de ses basic blocks est une étape essentielle.

ils l'ont implanté la sablevm, donc ça doit marcher en x86 :?

(je ne veux pas recopier le code qu'ils ont, je veux comprendre comment faire cela pour l'appliquer à ma machine virtuelle ;))

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je te suggere de regarder l'assembleur (gcc -S). gcc implemente les return par des sauts a l'epilogue. Et vu que ces sauts sont relatifs, ca ne va jamais marcher par copie.

---

j'y ai pensé... mais je n'ai pas réussi à comprendre l'erreur (mon niveau en asm n'est pas terrible... souvent je génère de l'asm, mais je ne l'écris pas à la main ;))

je vais remettre le code

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

int blockExecute() { size_t size = &&block_end - &&block_begin; void* buf = malloc(size+1); void* block = memcpy(buf, &&block_begin, size); int i = 2; goto *block;   block_begin: { i *= 3; } block_end: return i;   }

---

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 42 43 44

blockExecute: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi subl $32, %esp movl $.L2, %edx movl $.L3, %eax movl %edx, %ecx subl %eax, %ecx movl %ecx, %eax movl %eax, -24(%ebp) movl -24(%ebp), %eax addl $1, %eax movl %eax, (%esp) call malloc movl %eax, -20(%ebp) movl -20(%ebp), %eax movl -24(%ebp), %edx movl %eax, %edi movl $.L3, %esi cld movl %edx, %ecx rep movsb movl %eax, -16(%ebp) movl $2, -12(%ebp) movl -16(%ebp), %eax jmp *%eax .L3: movl -12(%ebp), %eax movl %eax, %edx addl %edx, %edx leal (%edx,%eax), %eax movl %eax, -12(%ebp) .L2: movl -12(%ebp), %eax addl $32, %esp popl %esi popl %edi popl %ebp ret .size blockExecute, .-blockExecute .section .rodata

---

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'ai tendance a mettre ca en rapport avec les implementations de Forth. Tiens une page sur le sujet http://www.complang.tuwien.ac.at/for...aded-code.html a l'air de l'attribuer (ou des variantes proches) a Charles Moore en 1970. R.K. Dewar a employe des techniques semblables pour SPITBOL.

---

à ma connaissance, le premier papier sur le threaded code date de 1973 (James R. Bell, Communications of the ACM)

votre exemple date de 1993 (Anton Ertl, A Portable Forth Engine)

quant à moi, j'en utilise une version différente (qui ajoute aussi quelques inlining)
papier de 1998 Optimizing direct threaded code by selective inlining par Ricardi et Piumarta

c'était la première étape de mon travail... elle m'a fait gagner entre 15 et 50% de performances, suivant le type de code qu'on exécute ;)

je suis désormais dans la deuxième étape de mon travail qui consiste à construire ces basic blocks... pour pouvoir commencer la troisième étape, qui est pour le moment "secrète", et qui devrait me permettre de gagner encore près de 15-20% de perfs en échange d'un peu de mémoire ;)

Citation:

---

Envoyé par gorgonite

j'y ai pensé... mais je n'ai pas réussi à comprendre l'erreur

---

L'erreur est celle que j'indique. Avec ce que tu donnes ici, tu copies ce qu'il y a entre .L2 et .L3 qui ne contient pas d'instructions de saut ni de return a la fin. Donc tu executes n'importe quoi.

(Note que les problemes se combinent peut-etre avec l'impossibilite d'executer le code dans le tas, plutot que d'allouer avec malloc, essaye de mmap avec les flags qui autorisent l'execution).

On commence a sortir pas mal du cadre du C. C'est quoi un forum adequat?

Citation:

---

Envoyé par gorgonite

à ma connaissance, le premier papier sur le threaded code date de 1973 (James R. Bell, Communications of the ACM)

votre exemple date de 1993 (Anton Ertl, A Portable Forth Engine)

---

La page que j'ai donnee a une section historique qui attribue a C. Moore l'invention du threaded code avec ce meme papier de Bell comme premiere publication.

Citation:

---

Envoyé par Jean-Marc.Bourguet

On commence a sortir pas mal du cadre du C. C'est quoi un forum adequat?

---

le forum adequat... ben j'en vois pas :?
j'ose pas aller poster sur le forum assembleur, je ne code rien en assembleur :roll:

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

int blockExecute() { int fd = open("/dev/zero", O_RDWR); if (fd == -1) { perror("open"); exit(EXIT_FAILURE); } size_t size = 2*(&&block_end - &&block_begin) + &&block2_end-&&block2_end; unsigned char* buf = mmap(NULL, size, PROT_EXEC|PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0); if (buf == MAP_FAILED) { perror("mmap"); exit(EXIT_FAILURE); } unsigned char* block = buf; unsigned char* done = &&block2_end; memcpy(buf, &&block_begin, &&block_end - &&block_begin); buf += &&block_end - &&block_begin; memcpy(buf, &&block_begin, &&block_end - &&block_begin); buf += &&block_end - &&block_begin; memcpy(buf, &&block2_begin, &&block2_end - &&block2_begin); int i = 2; goto *block;   block_begin: { i *= 3; } block_end: block2_begin: { goto *done; } block2_end:; return i;   }

---

a l'air de fonctionner ici.

Citation:

---

Envoyé par Jean-Marc.Bourguet

... a l'air de fonctionner ici.

---

merci pour le bout de code, j'étais encore en train de débugger le mien ;)

en revanche, sur ma machine, le programme ne plante pas... mais ne s'arrête pas non plus :?

Citation:

---

Envoyé par gorgonite

en revanche, sur ma machine, le programme ne plante pas... mais ne s'arrête pas non plus :?

---

x86 linux, ca marche Sparc solaris ca marche.
Power AIX, ca plante. Mais mes connaissance en assembleur Power sont insuffisantes pour comprendre le probleme et j'ai pas le temps d'y plonger.

Citation:

---

Envoyé par Jean-Marc.Bourguet

x86 linux, ca marche Sparc solaris ca marche.
Power AIX, ca plante. Mais mes connaissance en assembleur Power sont insuffisantes pour comprendre le probleme et j'ai pas le temps d'y plonger.

---

bizarre je suis en x86 linux :?

Citation:

---

Envoyé par gorgonite

bizarre je suis en x86 linux :?

---

gdb, CTRL-C et desassembler ce qu'il y a autour.

tout marche jusqu'au goto *block;

puis ça ne veut plus :?

Citation:

---

Error accessing memory address 0x0: Input/output error.

---

mais j'arrive pas à déterminer plus précisement où ça plante


pour infos, j'ai gcc 4.1.2 sous Ubuntu

mmmmm la variable buf stockant une adresse fournie par mmap, ce serait pas mieux qu'elle soit en globale ??

là ton diagnostic sort *block est NULL, or block correspond à buf, qui correspond à mmap...


Enfin, c'que j'en dit.... Z'êtes trop sioux pour moi ... :cry:

Citation:

---

Envoyé par gorgonite

gcc 4.1.2

---

C'est l'explication. Amusant, si tu compiles en optimise, ca "fonctionne" mais ca donne un resultat incorrect.

C'est bien ce que je disais ci-dessus, la methode depend de trop de suppositions sur la maniere dont est genere le code, et ce meme sans optimisation avec gcc...

exact... ça marche

il ne me reste plus qu'à trouver une autre méthode ;)

Salut,


au fait, il y avait block2_end - block2_end au lieu de block2_end - block2_begin ;)


par ailleurs, le résultat renvoyée est 6... et non 12 (j'avais pas fait gaffe sur le coup :?)


enfin, si je rajoute un autre bloc, suivant ce que j'y mets, mmap envoie un message d'erreur différent

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

int testBlockExecute() { int fd = open("/dev/zero", O_RDWR); if (fd == -1) { perror("open"); exit(EXIT_FAILURE); } size_t size = (&&block_end - &&block_begin) + (&&blockBis_end - &&blockBis_begin) + (&&block2_end-&&block2_begin); unsigned char* buf = mmap(NULL, size, PROT_EXEC|PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0); if (buf == MAP_FAILED) { perror("mmap"); exit(EXIT_FAILURE); } unsigned char* block = buf; unsigned char* done = &&block2_end; memcpy(buf, &&block_begin, &&block_end - &&block_begin); buf += &&block_end - &&block_begin; memcpy(buf, &&blockBis_begin, &&blockBis_end - &&blockBis_begin); buf += &&blockBis_end - &&blockBis_begin; memcpy(buf, &&block2_begin, &&block2_end - &&block2_begin); int j, i=2; goto *block;   block_begin: i = 3; block_end: blockBis_begin: i = 5; blockBis_end: block2_begin: { goto *done; } block2_end: return i; }

---

contenu de blockBis

• i = 5; => mmap: Cannot allocate memory
• j = 5; => mmap: Invalid argument

y aurait-il un autre allocateur entre le malloc, calloc & cie et le mmap ?

au passage, j'ai tenté de ne pas passer par mmap, mais plutôt par malloc puis mprotect... afin d'éviter les erreurs bizarres de mmap :?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

int testBlockExecute() { size_t size = (&&block_end - &&block_begin) + (&&block2_end-&&block2_begin); unsigned char* buf = malloc(size); mprotect(buf,size,PROT_EXEC|PROT_READ|PROT_WRITE);   unsigned char* block = buf; memcpy(buf, &&block2_begin, &&block2_end - &&block2_begin);   int i=2; unsigned char* done = &&block2_end; goto *block;   block_begin: i *= 3; block_end: block2_begin: { goto *done; } block2_end: return i; }

---

mais, ça plante autant à l'exécution

Citation:

---

Trappe pour point d'arrêt et de trace (core dumped)

---

si quelqu'un a une solution, ou même une piste... ça m'arrangerait beaucoup :D

j'ai trouvé un commencement d'explication sur mon problème...

http://lists.apple.com/archives/Darw.../msg00021.html


malheureusement msync() ne change rien à la situation, et cacheflush ne semble pas disponible sous ma distribution (Ubuntu Feisty 7.0.4)


si quelqu'un voit comment refaire cette fonction sur une architecture x86, ça m'intéresse :)

au passage, mon code actuel est le suivant :

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 42 43 44 45 46 47 48

int testBlockExecute() { size_t size = (&&block_end - &&block_begin) + (&&block2_end-&&block2_begin); #ifndef NOT_MMAP unsigned char* buf = mmap(NULL, size, PROT_EXEC|PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); if (buf == MAP_FAILED) { perror("mmap"); exit(EXIT_FAILURE); } #else unsigned char* buf = malloc(size); if (buf == NULL) { perror("malloc"); exit(EXIT_FAILURE); } if (mprotect(buf,size,PROT_EXEC|PROT_READ|PROT_WRITE) != 0) { perror("mprotect"); exit(EXIT_FAILURE); } #endif   unsigned char* block = buf; memcpy(buf, &&block2_begin, &&block2_end - &&block2_begin);   if (msync(block,size,MS_INVALIDATE) != 0) { perror("msync"); exit(EXIT_FAILURE); } /* if (cacheflush(block,size,BCACHE) != 0) { perror("cacheflush"); exit(EXIT_FAILURE); }*/ int i=2; unsigned char* done = &&block2_end; fprintf(stderr,"début de l'exécution\n"); FUNCTYPE fn = (FUNCTYPE) block; fn(); goto *done;   block_begin: i *= 3; block_end: block2_begin: { goto *done; } block2_end: return i; }

---

Je crains que ton approche soit vouee a etre fragile et a dependre fortement du systeme et du compilateur. En changer ou changer les options risque de tout casser.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je crains que ton approche soit vouee a etre fragile et a dependre fortement du systeme et du compilateur. En changer ou changer les options risque de tout casser.

---

j'ai bien compris... mais je n'en ai pas encore trouver d'autres (si ce n'est faire ce morceau direct en asm pour être sûr que le compilo ne le casse pas :?)

pour infos, en -O0 ceci fonctionne...

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 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

#include <sys/mman.h> #include <stdio.h> #include <stdlib.h> #include <string.h>     int testBlockExecute() { size_t size; unsigned char *buf; unsigned char *block; int i = 2; unsigned char *done;   int (*pputs)(const char*)=&puts; done = &&end; size = (&&block_end - &&block_begin) + (&&block2_end - &&block2_begin); size += (&&blockBis_end - &&blockBis_begin); fprintf(stderr,"size buf\t%d\n",size);   buf = mmap(NULL, size, PROT_EXEC|PROT_READ|PROT_WRITE, MAP_PRIVATE|0x20, -1, 0); if (buf == MAP_FAILED) { perror("mmap"); exit(EXIT_FAILURE); }   block = buf;   memcpy(buf, &&block_begin, &&block_end - &&block_begin); buf += &&block_end - &&block_begin; memcpy(buf, &&blockBis_begin, &&blockBis_end - &&blockBis_begin); buf += &&blockBis_end - &&blockBis_begin; memcpy(buf, &&block2_begin, &&block2_end - &&block2_begin); buf += &&block2_end - &&block2_begin;   if (msync(block, size, MS_INVALIDATE) != 0) { perror("msync"); exit(EXIT_FAILURE); }   fprintf(stderr,"début de l'exécution\n"); goto *block; fprintf(stderr,"ce morceau n'est pas atteignable\n");     blockBis_begin: i /= 5; blockBis_end:   block_begin: pputs("addition"); i *= 3; block_end:       block2_begin: { __asm__ volatile ("jmp *%0" : : "m" (done)); } block2_end:   end:   return i;   }   int main (void) { int i;   i = testBlockExecute(); printf("%d\n", i);   return EXIT_SUCCESS; }

---

si vous passez à -01 ou -0s, le pputs fait un segfault, et de toute façon, sans lui, ça renvoie 0 au lieu de 1 (comme si les instructions n'étaient plus exécutées dans le même ordre :cry:)

Je remets une couche et apres j'arrete, c'est promis.

Pour fonctionner correctement, ce genre de code fait beaucoup d'hypotheses sur la maniere dont le compilateur genere du code. Ces hypotheses peuvent sembler raisonnables, mais le fait qu'il y a des problemes meme avec gcc -O0 montre qu'il n'en est rien.

Ca va avoir l'air de fonctionner et casser apres un changement anodin qui fera que la generation de code sera legerement differente.