Changes between Version 7 and Version 8 of Archi-1-TD10

Timestamp:

May 16, 2022, 9:35:24 AM (3 years ago)

Author:

franck

Comment:

--

Archi-1-TD10

@@ -140 +140 @@
 
 
-
-= 2. Langage C pour la programmation système
-
-
-
-
-La programmation en C, vous connaissez, mais quand on programme pour le noyau, c'est un peu différent. 
-Il y a des éléments de syntaxe ou des besoins spécifiques. Pour répondre aux questions, vous devez avoir lu les transparents 33 à 53 du cours 10, dans lesquels une séquence complète de code (du boot à exit) est détaillée.
-
-
-**Questions**
-
-
-1. En assembleur, vous utilisez les sections prédéfinies `.data` et `.text` pour placer respectivement les data et le code, mais vous pouvez créer vos propres sections avec la directive `.section` (nous avons utilisé cette possibilité pour la section `.boot`). Il est aussi possible d'imposer ou de créer des sections en langage C avec la directive `__attribute__((section("section-name")))`. La directive du C `__attribute__` permet de demander certains comportements au compilateur. Ici, c'est la création d'une section, mais il y a beaucoup d'attributs possibles (si cela vous intéresse vous pouvez regarder dans la [https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Variable-Attributes.html doc de GCC sur les attributs]. Comment créer la section `.start` en C ?
-{{{#!protected ------------------------------------------------------------------------------------
-''
-Cours 10 / slide 38
-- `__attribute__ ((section (".start")))`\\La syntaxe est un peu curieuse avec les doubles underscore et les doubles parenthèses.
-''
-}}}
-1. En C, vous savez que les variables globales sont toujours initialisées, soit explicitement dans le programme lui-même, soit implicitement à la valeur `0`. Les variables globales initialisées sont placées dans la section `.data` (ou plutôt dans l'une des sections `data` : `.data`, `.sdata`, `.rodata`, etc.) et elles sont présentes dans le fichier objet (`.o`) produit pas le compilateur. En revanche, les variables globales non explicitement initialisées ne sont pas présentes dans le fichier objet. Ces dernières sont placées dans un segment de la famille [https://www.wikiwand.com/fr/Segment_BSS `.bss`]. Le fichier ldscript permet de mapper l'ensemble des segments en mémoire. Pour pouvoir initialiser à `0` les segments `bss` par programme, il nous faut connaître les adresses de début et de fin où ils sont placés en mémoire.\\ \\Le code ci-dessous est le fichier ldscript du kernel `kernel.ld` (nous avons retiré les commentaires mais ils sont dans les fichiers).\\Expliquez ce que font les lignes 11, 12 et 15.
-{{{#!java
-  1 SECTIONS
-  2 {
-  3     .boot : {
-  4         *(.boot)            
-  5     } > boot_region
-  6     .ktext : {
-  7         *(.text*)           
-  8     } > ktext_region
-  9     .kdata : {
- 10         *(.*data*)          
- 11         . = ALIGN(4);       
- 12         __bss_origin = .;   
- 13         *(.*bss*)           
- 14         . = ALIGN(4);       
- 15         __bss_end = .;      
- 16     } > kdata_region
- 17 }
-}}}
-{{{#!protected ------------------------------------------------------------------------------------
-''
-Cours 10 / slide 28
-- La ligne 11 contient `. = ALIGN(4)`, c'est équivalent à la directive `.align 4` de l'assembleur.
-  Cela permet de déplacer le pointeur de remplissage de la section de sortie courante (c'est-à-dire ici `.kdata`) sur une
-  frontière de 2^4^ octets (une adresse multiple de 16). Cette contrainte est liée aux caches que nous ne verrons pas ici.
-- La ligne 12 permet de créer la variable de ldscript `__bss_origin` et de l'initialiser à l'adresse courante, 
-  ce sera donc l'adresse de début de la zone `bss`.
-- La ligne 15 permet de créer la variable `__bss_end` qui sera l'adresse de fin de la zone `bss` 
-  (en fait c'est la première adresse qui suit juste `bss`. 
-''
-}}}
-1. Nous connaissons les adresses des registres de périphériques. Ces adresses sont déclarées dans le fichier ldscript `kernel.ld`. Ci-après, nous avons la déclaration de la variable de ldscript `__tty_regs_map`. Cette variable est aussi utilisable dans les programmes C, mais pour être utilisable par le compilateur C, il est nécessaire de lui dire quel type de variable c'est, par exemple une adresse d'entier ou une adresse de tableau d'entiers, Ou encore, une adresse de structure.\\ \\Dans le fichier `kernel.ld`:
-{{{#!c
-__tty_regs_map   = 0xd0200000 ; /* tty's registers map, described in devices.h */
-}}}
-   Dans le fichier `harch.c` :
-{{{#!c
- 12 struct tty_s {
- 13     int write;          // tty's output address
- 14     int status;         // tty's status address something to read if not null)
- 15     int read;           // tty's input address
- 16     int unused;         // unused address
- 17 }; 
- 18 
- 19 extern volatile struct tty_s __tty_regs_map[NTTYS];
-}}}
-  À quoi servent les mots clés `extern` et `volatile` ?\\Si `NTTYS` est une macro dont la valeur est `2`, quelle est l'adresse en mémoire `__tty_regs_map[1].read` ?
-{{{#!protected ------------------------------------------------------------------------------------
-''
-Cours 10 / slide 53
-- `extern` : informe le compilateur que la variable définie existe ailleurs. Grâce à son type, le compilateur sait s'en servir.
-- `volatile` : informe le compilateur que la variable peut changer de valeur toute seule et que donc il doit toujours accéder en mémoire à chaque fois que le programme le demande. Il ne peut donc pas optimiser les accès mémoire en utilisant les registres.
-- `__tty_regs_map` est un tableau à 2 cases (puisque `NTTYS`=`2`).\\Chaque case est une structure de 4 entiers, donc `0x10` octets (16 octets).\\`read` est le troisième champ, c'est le troisième entier de la structure, donc en `+8` par rapport au début.\\En conséquence `__tty_regs_map[1].read` est en `0xd0200018`
-''
-}}}
-1. Certaines parties du noyau sont en assembleur. Il y a au moins les toutes premières instructions du code de boot (démarrage de l'ordinateur) et l'entrée dans le noyau (kentry) après l'exécution d'un syscall. Le gestionnaire de syscall est écrit en assembleur et il a besoin d'appeler une fonction écrite en langage C. Ce que fait le gestionnaire de syscall est: 
- - trouver l'adresse de la fonction C qu'il doit appeler pour exécuter le service demandé;
- - placer cette adresse dans un registre, nous utilisons le registre `$2`;
- - exécuter l'instruction `jal` (ici, `jal $2`) pour appeler la fonction.
-
- Que doivent contenir les registres `$4` à `$7` et comment doit-être la pile et le pointeur de pile?
-{{{#!protected ------------------------------------------------------------------------------------
-''
-Cours 10 / slide 42
-- C'est un appel de fonction, il faut donc respecter la convention d'appel des fonctions
-  - Les registres `$4`à `$7` contiennent les arguments de la fonction
-  - Le pointeur de pile doit pointer sur la case réservée pour le premier argument et les cases suivantes sont réservées arguments suivants.
-  - Ce n'est pas rappelé ici, mais, **pour l'application user**, il y a **au plus** 4 arguments (entier ou pointeur) pour tous les syscalls. Le gestionnaire de syscall ajoute un cinquième argument avec le numéro de service qu'il a reçu dans `$2`. En conséquence, le pointeur de pile pointe au début d'une zone vide de 4 entiers suivi d'un 5e avec le numéro du service.
-  - L'intérêt d'ajouter le numéro de service comme cinquième argument, c'est qu'il est possible de faire une fonction unique qui gère un ensemble de syscalls avec un `switch/case` sur le numéro de service. On ne le fait pas dans cette version.
-''
-}}}
-5. Vous avez appris à écrire des programmes assembleur, mais parfois il est plus simple, voire nécessaire, de mélanger le code C et le code assembleur. Dans l'exemple ci-dessous, nous voyons comment la fonction `syscall()` est écrite. Cette fonction utilise l'instruction `syscall`.\\Deux exemples d'usage de la fonction `syscall()` pris dans le fichier `tp2/4_libc/ulib/libc.c`
-{{{#!c
-  1 int fprintf (int tty, char *fmt, ...)
-  2 {
-  3     int res;
-  4     char buffer[PRINTF_MAX];
-  5     va_list ap;
-  6     va_start (ap, fmt);
-  7     res = vsnprintf(buffer, sizeof(buffer), fmt, ap);
-  8     res = syscall (tty, (int)buffer, 0, 0, SYSCALL_TTY_PUTS);
-  9     va_end(ap);
- 10     return res;
- 11 }
- 12 
- 13 void exit (int status)
- 14 {
- 15     syscall( status, 0, 0, 0, SYSCALL_EXIT);        // never returns
- 16 }
-}}}
- 
- Le code de cette fonction est dans le fichier `tp2/4_libc/ulib/crt0.c`
-{{{#!c
-  1 //int syscall (int a0, int a1, int a2, int a3, int syscall_code)
-  2 __asm__ (
-  3 ".globl syscall     \n"         
-  4 "syscall:           \n"         
-  5 "   lw  $2,16($29)  \n"         
-  6 "   syscall         \n"         
-  7 "   jr  $31         \n"         
-  8 );
-}}}
- Combien d'arguments a la fonction `syscall()`?
- Comment la fonction `syscall()` reçoit-elle ses arguments ?
- A quoi sert la ligne 3 de la fonction `syscall()` et que se passe-t-il si on la retire ?
- Expliquer la ligne 5 de la fonction `syscall()`.
- Aurait-il été possible de mettre le code de la fonction `syscall()` dans un fichier `.S` ? 
-{{{#!protected ------------------------------------------------------------------------------------
-''
-Cours 10 / slide 40
-- La fonction `syscall()` a 5 a arguments
-- Elle reçoit ses 4 premiers arguments dans les registres $4 à $7 et le 5e (le numéro de service) dans la pile.
-- La ligne 3 sert à dire que syscall est une étiquette utilisée dans un autre fichier. `.globl` signifie **glob**al **l**abel. Si on la retire, il y aura un problème lors de l'édition de lien. `syscall()` ne sera pas trouvé par l'éditeur de liens.
-- Le noyau attend le numéro de service dans `$2`. Or le numéro du service est le 5e argument de la fonction `syscall()`. La ligne 5 permet d'aller le chercher dans la pile.
-- oui, ce code de la fonction `syscall()` qui fait appel à l'instruction `syscall` aurait pu être mis dans un fichier en assembleur, mais cela aurait demandé d'avoir un fichier de plus, pour une seule fonction. Dans une version plus évoluée du système, il y aura un d'autres fonctions assembleur, alors on créera un fichier assembleur pour les réunir.
-''
-}}}
-
-
-
-= 3. Passage entre les modes kernel et user
+= 2. Passage entre les modes kernel et user
 
 
@@ -469 +328 @@
 
 
+= 3. Langage C pour la programmation système
+
+
+
+
+La programmation en C, vous connaissez, mais quand on programme pour le noyau, c'est un peu différent. 
+Il y a des éléments de syntaxe ou des besoins spécifiques. Pour répondre aux questions, vous devez avoir lu les transparents de l'annexe du cours 10, dans lesquels une séquence complète de code (du boot à exit) est détaillée.
+
+
+**Questions**
+
+
+1. En assembleur, vous utilisez les sections prédéfinies `.data` et `.text` pour placer respectivement les data et le code, mais vous pouvez créer vos propres sections avec la directive `.section` (nous avons utilisé cette possibilité pour la section `.boot`). Il est aussi possible d'imposer ou de créer des sections en langage C avec la directive `__attribute__((section("section-name")))`. La directive du C `__attribute__` permet de demander certains comportements au compilateur. Ici, c'est la création d'une section, mais il y a beaucoup d'attributs possibles (si cela vous intéresse vous pouvez regarder dans la [https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Variable-Attributes.html doc de GCC sur les attributs]. Comment créer la section `.start` en C ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 10 annexe / slide 8
+- `__attribute__ ((section (".start")))`\\La syntaxe est un peu curieuse avec les doubles underscore et les doubles parenthèses.
+''
+}}}
+1. En C, vous savez que les variables globales sont toujours initialisées, soit explicitement dans le programme lui-même, soit implicitement à la valeur `0`. Les variables globales initialisées sont placées dans la section `.data` (ou plutôt dans l'une des sections `data` : `.data`, `.sdata`, `.rodata`, etc.) et elles sont présentes dans le fichier objet (`.o`) produit pas le compilateur. En revanche, les variables globales non explicitement initialisées ne sont pas présentes dans le fichier objet. Ces dernières sont placées dans un segment de la famille [https://www.wikiwand.com/fr/Segment_BSS `.bss`]. Le fichier ldscript permet de mapper l'ensemble des segments en mémoire. Pour pouvoir initialiser à `0` les segments `bss` par programme, il nous faut connaître les adresses de début et de fin où ils sont placés en mémoire.\\ \\Le code ci-dessous est le fichier ldscript du kernel `kernel.ld` (nous avons retiré les commentaires mais ils sont dans les fichiers).\\Expliquez ce que font les lignes 11, 12 et 15.
+{{{#!java
+  1 SECTIONS
+  2 {
+  3     .boot : {
+  4         *(.boot)            
+  5     } > boot_region
+  6     .ktext : {
+  7         *(.text*)           
+  8     } > ktext_region
+  9     .kdata : {
+ 10         *(.*data*)          
+ 11         . = ALIGN(4);       
+ 12         __bss_origin = .;   
+ 13         *(.*bss*)           
+ 14         . = ALIGN(4);       
+ 15         __bss_end = .;      
+ 16     } > kdata_region
+ 17 }
+}}}
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 10 / slide 28
+- La ligne 11 contient `. = ALIGN(4)`, c'est équivalent à la directive `.align 4` de l'assembleur.
+  Cela permet de déplacer le pointeur de remplissage de la section de sortie courante (c'est-à-dire ici `.kdata`) sur une
+  frontière de 2^4^ octets (une adresse multiple de 16). Cette contrainte est liée aux caches que nous ne verrons pas ici.
+- La ligne 12 permet de créer la variable de ldscript `__bss_origin` et de l'initialiser à l'adresse courante, 
+  ce sera donc l'adresse de début de la zone `bss`.
+- La ligne 15 permet de créer la variable `__bss_end` qui sera l'adresse de fin de la zone `bss` 
+  (en fait c'est la première adresse qui suit juste `bss`. 
+''
+}}}
+1. Nous connaissons les adresses des registres de périphériques. Ces adresses sont déclarées dans le fichier ldscript `kernel.ld`. Ci-après, nous avons la déclaration de la variable de ldscript `__tty_regs_map`. Cette variable est aussi utilisable dans les programmes C, mais pour être utilisable par le compilateur C, il est nécessaire de lui dire quel type de variable c'est, par exemple une adresse d'entier ou une adresse de tableau d'entiers, Ou encore, une adresse de structure.\\ \\Dans le fichier `kernel.ld`:
+{{{#!c
+__tty_regs_map   = 0xd0200000 ; /* tty's registers map, described in devices.h */
+}}}
+   Dans le fichier `harch.c` :
+{{{#!c
+ 12 struct tty_s {
+ 13     int write;          // tty's output address
+ 14     int status;         // tty's status address something to read if not null)
+ 15     int read;           // tty's input address
+ 16     int unused;         // unused address
+ 17 }; 
+ 18 
+ 19 extern volatile struct tty_s __tty_regs_map[NTTYS];
+}}}
+  À quoi servent les mots clés `extern` et `volatile` ?\\Si `NTTYS` est une macro dont la valeur est `2`, quelle est l'adresse en mémoire `__tty_regs_map[1].read` ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 10 annexe / slide 23
+- `extern` : informe le compilateur que la variable définie existe ailleurs. Grâce à son type, le compilateur sait s'en servir.
+- `volatile` : informe le compilateur que la variable peut changer de valeur toute seule et que donc il doit toujours accéder en mémoire à chaque fois que le programme le demande. Il ne peut donc pas optimiser les accès mémoire en utilisant les registres.
+- `__tty_regs_map` est un tableau à 2 cases (puisque `NTTYS`=`2`).\\Chaque case est une structure de 4 entiers, donc `0x10` octets (16 octets).\\`read` est le troisième champ, c'est le troisième entier de la structure, donc en `+8` par rapport au début.\\En conséquence `__tty_regs_map[1].read` est en `0xd0200018`
+''
+}}}
+1. Certaines parties du noyau sont en assembleur. Il y a au moins les toutes premières instructions du code de boot (démarrage de l'ordinateur) et l'entrée dans le noyau (kentry) après l'exécution d'un syscall. Le gestionnaire de syscall est écrit en assembleur et il a besoin d'appeler une fonction écrite en langage C. Ce que fait le gestionnaire de syscall est: 
+ - trouver l'adresse de la fonction C qu'il doit appeler pour exécuter le service demandé;
+ - placer cette adresse dans un registre, nous utilisons le registre `$2`;
+ - exécuter l'instruction `jal` (ici, `jal $2`) pour appeler la fonction.
+
+ Que doivent contenir les registres `$4` à `$7` et comment doit-être la pile et le pointeur de pile?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 10 annexe / slide 12
+- C'est un appel de fonction, il faut donc respecter la convention d'appel des fonctions
+  - Les registres `$4`à `$7` contiennent les arguments de la fonction
+  - Le pointeur de pile doit pointer sur la case réservée pour le premier argument et les cases suivantes sont réservées arguments suivants.
+  - Ce n'est pas rappelé ici, mais, **pour l'application user**, il y a **au plus** 4 arguments (entier ou pointeur) pour tous les syscalls. Le gestionnaire de syscall ajoute un cinquième argument avec le numéro de service qu'il a reçu dans `$2`. En conséquence, le pointeur de pile pointe au début d'une zone vide de 4 entiers suivi d'un 5e avec le numéro du service.
+  - L'intérêt d'ajouter le numéro de service comme cinquième argument, c'est qu'il est possible de faire une fonction unique qui gère un ensemble de syscalls avec un `switch/case` sur le numéro de service. On ne le fait pas dans cette version.
+''
+}}}
+5. Vous avez appris à écrire des programmes assembleur, mais parfois il est plus simple, voire nécessaire, de mélanger le code C et le code assembleur. Dans l'exemple ci-dessous, nous voyons comment la fonction `syscall()` est écrite. Cette fonction utilise l'instruction `syscall`.\\Deux exemples d'usage de la fonction `syscall()` pris dans le fichier `tp2/4_libc/ulib/libc.c`
+{{{#!c
+  1 int fprintf (int tty, char *fmt, ...)
+  2 {
+  3     int res;
+  4     char buffer[PRINTF_MAX];
+  5     va_list ap;
+  6     va_start (ap, fmt);
+  7     res = vsnprintf(buffer, sizeof(buffer), fmt, ap);
+  8     res = syscall (tty, (int)buffer, 0, 0, SYSCALL_TTY_PUTS);
+  9     va_end(ap);
+ 10     return res;
+ 11 }
+ 12 
+ 13 void exit (int status)
+ 14 {
+ 15     syscall( status, 0, 0, 0, SYSCALL_EXIT);        // never returns
+ 16 }
+}}}
+ 
+ Le code de cette fonction est dans le fichier `tp2/4_libc/ulib/crt0.c`
+{{{#!c
+  1 //int syscall (int a0, int a1, int a2, int a3, int syscall_code)
+  2 __asm__ (
+  3 ".globl syscall     \n"         
+  4 "syscall:           \n"         
+  5 "   lw  $2,16($29)  \n"         
+  6 "   syscall         \n"         
+  7 "   jr  $31         \n"         
+  8 );
+}}}
+ Combien d'arguments a la fonction `syscall()`?
+ Comment la fonction `syscall()` reçoit-elle ses arguments ?
+ A quoi sert la ligne 3 de la fonction `syscall()` et que se passe-t-il si on la retire ?
+ Expliquer la ligne 5 de la fonction `syscall()`.
+ Aurait-il été possible de mettre le code de la fonction `syscall()` dans un fichier `.S` ? 
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 10 annexe / slide 10
+- La fonction `syscall()` a 5 a arguments
+- Elle reçoit ses 4 premiers arguments dans les registres $4 à $7 et le 5e (le numéro de service) dans la pile.
+- La ligne 3 sert à dire que syscall est une étiquette utilisée dans un autre fichier. `.globl` signifie **glob**al **l**abel. Si on la retire, il y aura un problème lors de l'édition de lien. `syscall()` ne sera pas trouvé par l'éditeur de liens.
+- Le noyau attend le numéro de service dans `$2`. Or le numéro du service est le 5e argument de la fonction `syscall()`. La ligne 5 permet d'aller le chercher dans la pile.
+- oui, ce code de la fonction `syscall()` qui fait appel à l'instruction `syscall` aurait pu être mis dans un fichier en assembleur, mais cela aurait demandé d'avoir un fichier de plus, pour une seule fonction. Dans une version plus évoluée du système, il y aura un d'autres fonctions assembleur, alors on créera un fichier assembleur pour les réunir.
+''
+}}}
+
+
+
 = 4. Génération du code exécutable