Changes between Version 34 and Version 35 of Archi-1-TP10
- Timestamp:
- Jan 2, 2021, 12:23:30 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archi-1-TP10
v34 v35 361 361 ''''''''''''''' 362 362 }}} 363 1. Le gestionnaire de syscall est la partie du code qui gère le comportement du noyau lors de l'exécution de l'instruction `syscall`. C'est un code en assembleur présent dans le fichier `kernel/hcpu.S` que nous allons observer. Pour vous aider dans la compréhension de ce code, vous devez imaginer que l'instruction `syscall` est un peu comme un appel de fonction. Ce code utilise un tableau de pointeurs de fonctions nommé `syscall_vector` définit dans le fichier `kernel/ksyscalls.c`. Les lignes `36` à `43` sont chargées d'allouer dans la pile. Dessinez l'état de la pile après l'exécution de ces instructions. Que fait l'instruction lige `44` et quelle conséquence cela a? Que font les lignes `46` à `51`? Et enfin que font les lignes `53` à `59` \\ \\**`common/syscalls.h`**363 1. Le gestionnaire de syscall est la partie du code qui gère le comportement du noyau lors de l'exécution de l'instruction `syscall`. C'est un code en assembleur présent dans le fichier `kernel/hcpu.S` que nous allons observer. Pour vous aider dans la compréhension de ce code, vous devez imaginer que l'instruction `syscall` est un peu comme un appel de fonction. Ce code utilise un tableau de pointeurs de fonctions nommé `syscall_vector` définit dans le fichier `kernel/ksyscalls.c`. Les lignes `36` à `43` sont chargées d'allouer dans la pile. Dessinez l'état de la pile après l'exécution de ces instructions. Que fait l'instruction lige `44` et quelle conséquence cela a? Que font les lignes `46` à `51`? Et enfin que font les lignes `53` à `59` sans détailler ligne à ligne.\\ \\**`common/syscalls.h`** 364 364 {{{#!c 365 365 1 #define SYSCALL_EXIT 0 … … 397 397 48 sll $2, $2, 2 398 398 49 addu $2, $26, $2 399 50 lw $2, ($2)399 50 lw $2, 0($2) 400 400 51 jalr $2 401 401 52 … … 431 431 }}} 432 432 - L'instruction ligne 44 met `0` dans le registre `c0_sr`. Ce qui a pour conséquence de mettre à `0` les bits `UM`, `EXL` et `IE`. On est donc en mode kernel avec interruptions masquées.\\ \\''Notez qu'interdire les interruptions pendant l'exécution des syscall est contraignant. Pour le moment, ce n'est pas important puisque nous ne traitons pas encore les interruptions, mais lorsque nous les traiterons, elles seront masquées. En conséquence, il sera interdit aux fonctions qui traitent les appels système d'exécuter des attentes longues (comme une boucle qui attend le changement d'état d'un registre de périphérique) car sinon, le noyau sera bloqué (plus rien ne bouge).'' 433 - Commentaire du code 433 - Commentaire du code ligne 46 à 53 434 434 - Ligne 46 : `$26` **←** l'adresse du tableau syscall_vector\\⟶ On s'apprête à y faire un accès indexé par le registre `$2` 435 435 - Ligne 47 : `$2` **←** `$2 & 0x1F`\\⟶ pour éviter de sortir du tableau si l'utilisateur à mis n'importe quoi dans `$2` 436 436 - Ligne 48 : `$2` **←** `$2 * 4`\\⟶ Les cases du tableau sont des pointeurs et font 4 octets 437 - Ligne 49 : `$2` **←** `$26 + $2`\\⟶ 438 - Ligne 50 : **←** \\⟶ 439 - Ligne 51 : **←** \\⟶ 437 - Ligne 49 : `$2` **←** `$26 + $2`\\⟶ `$2` contient désormais l'adresse de la case contenant la fonction correspondante au service n°`$2` 438 - Ligne 50 : `$2` **←** MEM[`$2`] \\⟶ $2 contient l'adresse de la fonction a appeler 439 - Ligne 51 : jal $2 \\⟶ appel de la fonction de service\\On rappelle que `$4` à `$7` et qu'il y a de place pour ces arguments dans la pile. 440 - Les lignes 53 à 59 restorent l'état des registres `$31`, `c0_status`, `c0_epc` et le pointeur de pile puis on sort du noyau avec l'instruction `eret`. 440 441 ''''''''''''''' 441 442 }}}
