Utiliser les exceptions pour un traitement particulier ?

Version imprimable

24/11/2004, 16h21
Blustuff

Utiliser les exceptions pour un traitement particulier ?

Bonjour : )

Je crois que j'ai déjà posé la question, mais peut être mal, ou alors pas aux bonnes personnes. ^^ Donc, je cherche à utiliser, et d'abord si c'est possible, les exceptions pour effectuer un traitement particulier.

J'ai une zone de mémoire, certaines parties peuvent être utilisées normalement pour la lecture et l'écriture. Les parties qui ne sont pas autorisées, déclancheraient des exceptions récupérées par un gestionaire qui effectuerait un traitement particulier suivant l'action illicite.

Je connais très mal les mécanisme d'exception et de mappage de la mémoire, donc, actuellement, j'ai du mal à imaginer si la chose est possible ou non, ou simplement pure fiction. Ou alors, si elle est possible quelles sont les contraintes, ou plutôt si elle n'est pas tout à fait possible, que faut il rajouter comme contrainte pour que ca devienne possible ? ^^

Blustuff.
25/11/2004, 01h15
Neitsa

Bonjour Blustuff,

Je pourrais toujours te répondre si ton cas concerne Windows...sinon ca n'est plus de mon domaine.

Sous Windows, la mémoire est gérée en interne par le Kernel. Néanmoins celui ci offre certaines fonctionnalités au processus en user mode (ring3) dont notemment la possibilité de mappé des pages mémoire et de les protégées/déprotégées à la volés. Toute tentative d'écriture sur une page qui serait en mode R (Read) uniquement déclenche obligatoirement une exception. Ensuite avec un gestionnaire d'exception (SEH) approprié on peut facilement récupérer tout un tas d'information.

Tout dépend de la mesure que tu veux prendre après le déclenchement de l'exception.

Amicalement, Neitsa.

J'avais déjà regardé l'API Win 32 pour tenter de trouver ces informations. Il me semble qu'il y a des contraintes pour le mappage. La zone de mémoire physique et/ou l'adresse de mappage devraient être alignées. Si c'est le cas, ces contraintes ne me gêne pas. Par contre, ce qui m'avait gêné je crois, c'est que s'il j'avais trouvé le moyen de mapper une autre zone de mémoire, je ne pouvais pas choisir quelle adresse lui sera attribuée.

Je cherche à établir un mappage du genre :
Code:

1 2 3 4 5 6 7 Gestionaire 1 Gestionaire 3 ^ Gestionaire 2 ^ | ^ | | | | +----------+---------------+--------+-------- | Zone 1 | Zone 2 | Zone 3 | . . . +----------+---------------+--------+------
Donc une grande zone de mémoire qui regrouperait toutes les zones, qui devraient être à la suite, mais suivant la zone, une exception aurait lieue ou non, etc.

Auriez vous quelques pistes de fonction de l'API Win32 à me donner ?

Blustuff.

25/11/2004, 02h44
Neitsa

Le problème pour la taille de la page est l'allocation de granularité qui fixe une base minimale pour la taille de page. Après avoir testé sous Win2k SP4, j'obtiens 0x10000 octets minimum pour une page (soit 64 Kibioctets) ce qui doit être pareil sous les autres NT (à tester sous les 9x).

Pour ce qui est de l'adresse, c'est un peu plus compliqué. Comme chaque processus se voit doter de son propre espace d'adressage, celui ci est généralement assez plein. On commence de 0x10000 pour aller à 0x7FFFFFFF pour les processus User mode. Windows ne laisse généralement pas trop le choix pour la base de la Page qu'on souhaite réserver.

Néanmoins si on alloue une page pas trop grosse, on a de bonne chance de pouvoir en allouer plusieurs à suivre. On peut alors réserver des régions contigües.

L'API VirtualAlloc est la pièce maitresse de l'allocation de mémoire (les fonction Global/Local et de heap sont moins intéressantes). De plus cette API permet de choisir le type de page:

R (read) / W(write) / RW / Ex(executable)

tout ces flags sont combinables entre eux. Ont peut réserver des pages COMMIT ou RESERVED (cf. MSDN). Les pages COMMIT sont initailisés et atteignables alors qu'une RESERVED n'est que...réservée (mais non atteignable, en fait on ne peut plus l'allouée).

Une option intéressante et le "one shot" exception avec le flag "PAGE_GUARD", qui permet de déclencher une exception (une seule fois).

Sinon, il est possible de mettre un page en Read seulement et en cas d'écriture de déclencher une exception. Si on ne veut pas d'exception, il suffit de mettre le flag à W. Il est toujours possible de changer la protection d'une page mappée avec VirtualAlloc grâce à l'API VirtualProtect.

En cas de déclenchement d'exception, on peut retrouver sur la pile (en fait dans la structure EXCEPTION_RECORD; membre ExceptionInformation), l'adresse où l'erreur s'est produite. En regardant l'adresse de la base de chaque mémoire allouée et leurs tailles on peut alors en déduire dans quelle bloc mémoire l'exception s'est produite (même si les page mémoire sont non contigües).

Neitsa.

En fait, j'ai trouvé quelques informations dont vous parlez avant de vous avoir lu, et utilisé donc Virtual Alloc pour faire un truc assez chaotique. J'ai décrété que ma zone allait commencer à 0x00040000, (entre la place du premier dll et du module, y'a toujours de la place ^^) quelle allait être de taille 2 x Granularité, puis suivie d'une zone en lecture seule de taille = Granularité. L'execution du programme donne :
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 Page Size : 4096 Minimum Application Adress 00010000 Maximum Application Adress : 7FFEFFFF Allocation Granularity : 65536 Lecture : 00040000 : 0 00044000 : 0 00048000 : 0 0004C000 : 0 00050000 : 0 00054000 : 0 00058000 : 0 0005C000 : 0 00060000 : 0 00064000 : 0 00068000 : 0 0006C000 : 0 Ecriture : 00040000 <- 17 00044000 <- 17 00048000 <- 17 0004C000 <- 17 00050000 <- 17 00054000 <- 17 00058000 <- 17 0005C000 <- 17
Où on a bien l'exception qui se produit arrivé à 0x00060000, donc tout va bien ! Je pense que si la granularité n'est pas plus élevée que 64 ca peut suffire pour ce que j'ai à faire, mais, ca dépend apparement de la machine, et on ne sait jamais... Mais alors, j'ai quelques questions :

Citation:

Envoyé par API Win32 un peu obsolète, mais j'avais la flemme de chercher sur MSDN

lpAddress

Specifies the desired starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the next 64-kilobyte boundary. If the memory is already reserved and is being committed, the address is rounded down to the next page boundary. To determine the size of a page on the host computer, use the GetSystemInfo function. If this parameter is NULL, the system determines where to allocate the region.

Ce qui est étrange, c'est qu'ici on parle d'aligment 64 K, alors que je pensais que ca dépendait que de la granularité, qui certes à tendance à être de 64 K, mais question quand même : / Ensuite, si on a réservé, l'adresse est pas obligée d'être alignée sur 64 K, mais sur la taille de la page (soit 4 K chez moi) ? Là, je trouve ca plutôt étrange, ou je sais pas lire l'anglais, ou je comprends rien...

Citation:

Envoyé par Idem

PAGE_NOCACHE
Allows no caching of the committed regions of pages. The hardware attributes for the physical memory should be specified as "no cache." This is not recommended for general usage. It is useful for device drivers; for example, mapping a video frame buffer with no caching. This flag is a page protection modifier, only valid when used with one of the page protections other than PAGE_NOACCESS.

J'ai pas compris ce paramètre, mais je pense qu'il peut m'être utile. Enfin, j'ai pas compris, c'est relatif : Je pense que ca veut dire que le processeur ne va jamais utiliser le cache. Il est expliqué que c'est utile pour un vidéo frame buffer, ce qui m'interesse encore plus ! Effectivement, j'ai souvenir que la mémoire vidéo n'était jamais en cache. Mais je ne me souviens pas si c'était par ce que c'était pas possible, ou si parce qu'il y avait un quelconque interêt. Une idée ?

D'après ce que tu as écrit plus haut tu risques de n'avoir pas de meilleure réponses à cette question : Je cherche à allouer x octets, avant de commencer mon mapping, et puisque je n'ai pas trop envie de tester pour toutes les adresses divisible par la granularité, j'aimerais que Windows me dise où est-ce que je peux mapper mes x octets. Et je n'ai pas trouvé de fonction pour ça :/

Et enfin pour terminer, je ne sais pas du tout comment intercepter les exception, c'est dans la FAC ?

Blustuff.

25/11/2004, 17h15
Neitsa

Bonjour,

Je reprend ce que j'ai dis dans mon deuxième post.

La granularité ne concerne pas la taille des pages mais plutôt leurs alignement en mémoire. Ainsi on ne peut aligner une page mémoire que tout les 64K (il me semble néanmoins qu'on puisse avoir une plage légèrement plus basse sous les environnement NT).

Néanmoins la taille de page est bien alignée sur 4K (c'est une spécificité des x86), ainsi, si on désire alloué 18K on aura une page de 20K (l'arrondi est fait vers le haut , ce qui semble tout à fait logique).

Le flag "PAGE_NOCACHE" indique comme quoi la page est en "nonpaged" ce qui signifie simplement qu'elle reste résidente en mémoire vive et n'est donc jamais déchargée sur le disque.

Citation:

j'aimerais que Windows me dise où est-ce que je peux mapper mes x octets. Et je n'ai pas trouvé de fonction pour ça :/

Il n'existe pas de manière vraiment simple de faire ca, néanmoins j'avais déjà écrit un programme en asm Win32 à cet effet, cherchant à savoir où je pouvais mapper mes pages en ayant le choix de l'adresse de base (choix restreint certes, mais choix qd même). Je vais tâcher de retrouver le source.

De mémoire il s'agissait de regarder l'état de chaque page, depuis la base jusqu'en haut de l'espace d'adressage du processus, pour voir si elles étaient "commit" ou "reserved" (dans le cas contraire, "non allouée"). Ensuite il suffisait de garder un pointeur sur le page non allouée et d'en faire un tableau.

Citation:

je ne sais pas du tout comment intercepter les exception

La mise ne place d'un SEH n'est pas très complexe. Je te conseille de suivre le tutorial de Jeremy Gordon pour les SEH sous windows en asm, surement le meilleur tutorial à cet effet :

http://www.jorgon.freeserve.co.uk/ExceptFrame.htm

Si jamais tu rencontre un problème, n'hésite pas.

Neitsa.

Merci pour les précisions sur l'alignement, c'est plus clair désormais : ) Mon niveau d'anglais me permet aisement de confondre les termes et les concepts : )

J'ai déjà en recherchant sur le forum trouvé le lien que vous avez donné, et constaté que vous êtes le seul à parler de cela sur ce forum. ^^ Pour l'instant j'ai utilisé le "Structured Exception Handling" de Microsoft pour intercepter les exceptions, mais j'ai quelques problèmes. Lorsque je met le traitement particulier dans la condition à évaluer du except :
Code:

1 2 3 4 5 6 7 try { ... } __except (Handler(GetExceptionInformation())) { }
(qui pour l'instant ne fait rien d'autre que d'afficher l'adresse où à lieue la lecture/écriture et si c'est une écriture ou une lecture) la fonction Handler est bien appellée un bon millier de fois (12288 fois pour être exact : ) ) pour une seule tentative d'écriture.

Si je code le Handler dans le bloc except :
Code:

1 2 3 4 5 6 7 8 9 10 __except ((Informations = GetExceptionInformation())->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH ) { cprintf(" - Violation d'acces : %s - Adresse : %p\r\n", Informations->ExceptionRecord->ExceptionInformation[0] ? "Ecriture" : "Lecture", Informations->ExceptionRecord->ExceptionInformation[1]); }
C'est non seulement pas très pratique, mais en plus, j'arrive pas à lui faire reprendre l'execution. (Elle sort du bloc except et termine le programme). Une idée ?

Enfin, j'ai quand même oublié une contrainte, et je ne peux pas trop faire de test, il ne faudrait pas que passer par les exceptions fasse perdre trop de temps, et d'après ce que j'ai pu comprendre, il y a pas mal de traitements suite à l'exception qui peuvent être un peu long. C'est peut être ce qui rendra la solution inexploitable.

Blustuff.

Héhé, j'ai voulu tester un truc, et dans la structure RECORD, j'ai ajouté 2 à eip, ce qui correspond par chance à la taille de l'instruction qui cause l'exception

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
Page Size : 4096
Minimum Application Adress 00010000
Maximum Application Adress : 7FFEFFFF
Allocation Granularity : 65536
 
Lecture :
 
00040000 : 0
00044000 : 0
00048000 : 0
0004C000 : 0
00050000 : 0
00054000 : 0
00058000 : 0
0005C000 : 0
00060000 : 0
00064000 : 0
00068000 : 0
0006C000 : 0
 
 
Ecriture :
 
00040000 <- 17
00044000 <- 17
00048000 <- 17
0004C000 <- 17
00050000 <- 17
00054000 <- 17
00058000 <- 17
0005C000 <- 17
00060000 <- 17 - Violation d'acces : Ecriture - Adresse : 00060000
00064000 <- 17 - Violation d'acces : Ecriture - Adresse : 00064000
00068000 <- 17 - Violation d'acces : Ecriture - Adresse : 00068000
0006C000 <- 17 - Violation d'acces : Ecriture - Adresse : 0006C000

Du coups, ca marche. La reprise de l'execution est sur l'instruction qui a causé l'exception. A vrai dire, j'aurais aimé que la reprise soit sur celle d'après :/

Enfin, ce qui m'interesse, compter le temps qu'il faut pour passer par un tel gestionnaire :

[edit] Une version qui n'affiche rien dans l'interval où l'on compte les cycles, c'est plus représentatif ^^ En désactivant le débugueur intégré aussi, ca divise le nombre de cycles par 10 : )[/edit]

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
Page Size : 4096
Minimum Application Adress 00010000
Maximum Application Adress : 7FFEFFFF
Allocation Granularity : 65536
 
Lecture :
 
00040000 -> 0 (9760 cylcles)
00044000 -> 0 (7482 cylcles)
00048000 -> 0 (7938 cylcles)
0004C000 -> 0 (7562 cylcles)
00050000 -> 0 (7305 cylcles)
00054000 -> 0 (7987 cylcles)
00058000 -> 0 (13656 cylcles)
0005C000 -> 0 (10792 cylcles)
00060000 -> 0 (12516 cylcles)
00064000 -> 0 (10709 cylcles)
00068000 -> 0 (10992 cylcles)
0006C000 -> 0 (14276 cylcles)
00070000 -> Violation d'Acces (52637 cylcles)
00074000 -> Violation d'Acces (18836 cylcles)
00078000 -> Violation d'Acces (36603 cylcles)
0007C000 -> Violation d'Acces (22688 cylcles)
 
 
Ecriture :
 
00040000 <- 17 (21 cylcles)
00044000 <- 17 (21 cylcles)
00048000 <- 17 (21 cylcles)
0004C000 <- 17 (21 cylcles)
00050000 <- 17 (21 cylcles)
00054000 <- 17 (21 cylcles)
00058000 <- 17 (21 cylcles)
0005C000 <- 17 (21 cylcles)
00060000 <- 17 Violation d'Acces (25602 cylcles)
00064000 <- 17 Violation d'Acces (16693 cylcles)
00068000 <- 17 Violation d'Acces (16655 cylcles)
0006C000 <- 17 Violation d'Acces (15685 cylcles)
00070000 <- 17 Violation d'Acces (20573 cylcles)
00074000 <- 17 Violation d'Acces (17296 cylcles)
00078000 <- 17 Violation d'Acces (17231 cylcles)
0007C000 <- 17 Violation d'Acces (17477 cylcles)
 
 
Lecture :
 
00040000 -> 17 (290 cylcles)
00044000 -> 17 (32 cylcles)
00048000 -> 17 (60 cylcles)
0004C000 -> 17 (32 cylcles)
00050000 -> 17 (32 cylcles)
00054000 -> 17 (60 cylcles)
00058000 -> 17 (32 cylcles)
0005C000 -> 17 (32 cylcles)
00060000 -> 0 (60 cylcles)
00064000 -> 0 (32 cylcles)
00068000 -> 0 (60 cylcles)
0006C000 -> 0 (60 cylcles)
00070000 -> Violation d'Acces (36022 cylcles)
00074000 -> Violation d'Acces (17880 cylcles)
00078000 -> Violation d'Acces (17251 cylcles)
0007C000 -> Violation d'Acces (29977 cylcles)

25602 cycles, c'est relativement honnereux comme méthode...

Pour info, voilà le code asm généré par le compilateur :

Code:

1
2
3
4
5
6
7
8
9
rdtsc
mov [A],eax
mov [A +0x4],edx
 
mov ecx,[edx]
 
rdtsc
mov [B],eax
mov [B +0x4],edx

30/11/2004, 00h54
Blustuff

Quelqu'un peut m'expliquer la cohérence des mesures effectuées ?

21 cycles en écriture de cache L1
32 - 60 cycles en lecture de cache L1
7 000 - 15 000 Cycles en lecture sur mémoire qui n'est pas en cache
17 000 - 50 000 Cycles sur exception

Ca contredit assez l'idée que j'avais des cycles...
30/11/2004, 15h20
Neitsa

Bonjour,

Le problème de mesure sur les cycles est vraiment compliqué.

L'instruction RDTSC devrait être accompagnée de CPUID permettant une sérialisation des instructions dans le pipe du CPU, de facon à ce que RDTSC ne soit pas exécutée avant les autres. Voir ce papier, par un ingé Intel à ce sujet:

http://www.math.uwaterloo.ca/~jamuir/rdtscpm1.pdf

Reste aussi le problème inhérent à Windows, qui fonctionne en "time-slice" (suivant un algorithme "round-robin schedule"). Ainsi chaque processus (ou plus spécifiquement chaque thread), se voit affecter un temps machine avant que l'O.S ne passe à un autre thread ou un autre processus.

Pendant ce temps là le TSC ("Time stamp counter" retourné justement par RDTSC) continue de défilé.

Tant qu'il n'y a pas bcp d'instructions à lire le problème n'entre pas en jeu, mais dès qu'il y a bcp d'instrutions dans un thread, on peut supposer que Windows aura donné la main à un autre thread pendant ce temps là. Il faudrait en théorie avoir un thread avec une priorité TIME_CRITICAL pour que les mesures se rapprochent d'une possible réalité... (sans tenir compte de l'O.S qui doit lui aussi exécuter son propre code...).

Le problème des exceptions et leut traitement relativement long est, je crois, du au fait que ce dernier s'accompagne de nombreuse APIs (notemment dans NTDLL) et de nombreux passages en Kernel Mode.
Autant de temps de perdu lorsqu'on à un compteur qui déroule pendant ce temps. Rien d'étonnant donc, à première vue, à ce qu'une exception prenne du temps pour être gérée.

par contre ce chiffre là est difficilement compréhensible:

Citation:

7 000 - 15 000 Cycles en lecture sur mémoire qui n'est pas en cache

tant qu'il n'y a pas d'utilisation d'API, 7000 cycles minimum pour une lecture c'est un peu gros... (en considérant qu'il n'y a pas eu de time-slice c-a-d de passage à un autre thread par l'O.S).

Il faudrait réitérer une bonne centaines de fois et voir si il n'y a pas quelques essais qui passent sous la barre des 100 cycles, confirmant ainsi un possible time-slice.

Sinon...je ne vois pas :)

Amicalement, Neitsa.
01/12/2004, 02h21
Blustuff

Eh bien, mis à part le problème des out-of-order il me semble que je connaissais déjà tous les points abordés dans le texte. Mais là, il n'y a pas vraiment ce problème.

Le problème de changement de thread ne pose pas non plus de problèmes, puisqu'ils doivent survenir à quelques millisecondes d'intervalles (si je ne me trompe pas ! Il me semble que j'avais écrit un programme qui vérifiait cela : un thread tournait à 1000 % de cpu, et un autre regardait quand il avait la main ! De plus ce temps concorde avec la fréquence à laquelle Windows utilise le timer, la même que celle utilisée par GetTickCount qui a de base une précision de 11 ms. Enfin, suite à un Sleep(0) c'est aussi le temps qu'il faut attendre), mon processeur étant un 1,2 GHz, on est très loin du million de cycles dans les mesures.

Enfin, ces mesures sont assez représentatives, puisque j'ai quand même executé le programme plusieurs fois afin de vérifier.