Changes between Version 97 and Version 98 of Archi-1-TP10
- Timestamp:
- Nov 28, 2021, 4:12:22 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archi-1-TP10
v97 v98 654 654 655 655 656 1. Ouvrez le fichier Makefile, En ouvrant tous les fichiers dessiner le graphe de dépendance de `kernel.x` vis-à-vis de ses sources? 657 {{{#!protected ------------------------------------------------------------------------------------ 658 '' '''''''''''''656 1. Ouvrez le fichier Makefile, En ouvrant tous les fichiers dessiner le graphe de dépendance de `kernel.x` vis-à-vis de ses sources?\\La réponse peut-être visible avec la commande `dot -Tpng Makefile.dot -oMakefile.png` à partir du fichier [htdocs:img/Makefile.dot Makefile.dot] en utilisant [https://www.graphviz.org graphviz] ... essayez c'est magique :-) 657 {{{#!protected ------------------------------------------------------------------------------------ 658 '' 659 659 {{{#!make 660 660 kernel.x : kernel.ld obj/hcpua.o obj/kinit.o obj/klibc.o obj/harch.o … … 664 664 obj/harch.o : harch.c harch.h 665 665 }}} 666 {{{667 digraph G {668 node [shape=box color=brown]669 gcc1[label="gcc -c"];670 gcc2[label="gcc -c"];671 gcc3[label="gcc -c"];672 gcc4[label="gcc -c"];673 ld[label="ld"];674 node [shape=ellipse color=blue]675 "hcpu.h" , "hcpua.S" -> gcc1 -> "obj/hcpua.o" -> ld -> "kernel.x"676 "kinit.c" , "klibc.h" -> gcc2 -> "obj/kinit.o" -> ld677 "klibc.h" , "klibc.c" , "harch.h" -> gcc3 -> "obj/klibc.o" -> ld678 "harch.h" , "harch.c" -> gcc4 -> "obj/harch.o" -> ld679 }680 }}}681 666 [[Image(htdocs:img/Makefile.png, width=500, nolink)]] 682 667 '' … … 684 669 1. Dans quel fichier se trouvent les codes dépendant du MIPS ? 685 670 {{{#!protected ------------------------------------------------------------------------------------ 686 '' '''''''''''''671 '' 687 672 - Ils sont dans le fichier `hcpua.S` 688 '' '''''''''''''673 '' 689 674 }}} 690 675 … … 713 698 }}} 714 699 }}} 700 701 715 702 == B2. Programme utilisateur mais exécuté en mode kernel 716 703 … … 720 707 Nous allons désormais avoir deux exécutables: le noyau et l'application. Dans cette étape, nous allons voir comment le noyau fait pour appeler l'application, alors même que celle-ci n'est pas compilée en même temps que le noyau. Nous allons passer du noyau à l'application à la fin de la fonction `kinit()`. 721 708 722 Nous allons donc entrer dans l'application, en revanche, dans cette étape, nous n'allons pas mettre en place la gestion des syscalls. C'est-à-dire qu'il ne sera pas possible de revenir dans le noyau depuis l'application. C'est bien entendu une étape intermédiaire, parce qu'il faut absolument pouvoir invoquer le noyau depuis l'application pour accéder aux périphériques.709 Nous allons donc entrer dans l'application, en revanche, dans cette étape, nous n'allons pas mettre en place la gestion des syscalls. **C'est-à-dire qu'il ne sera pas possible de revenir dans le noyau depuis l'application**. C'est bien entendu une étape intermédiaire, parce qu'il faut absolument pouvoir invoquer le noyau depuis l'application pour accéder aux périphériques. 723 710 Pour pouvoir quand même accéder aux registres de périphériques, nous allons **exceptionnellement** exécuter l'application en mode kernel. Ainsi, l'application pourra accéder aux adresses de l'espace d'adressage réservées au mode `kernel`. 724 711 … … 752 739 1. Combien de fichiers de type ldscript avons-nous ? 753 740 {{{#!protected ------------------------------------------------------------------------------------ 754 '' '''''''''''''741 '' 755 742 - Il en faut deux, un pour le kernel `kernel/kernel.ld` et un pour l'application `user/user.ld` 756 '' '''''''''''''743 '' 757 744 }}} 758 745 1. Dans quel fichier se trouve la première fonction de l'application et comment s'appelle-t-elle? 759 746 {{{#!protected ------------------------------------------------------------------------------------ 760 '' '''''''''''''747 '' 761 748 - Dans le fichier `user/crt0.c`, c'est la fonction `_start()`. 762 '' '''''''''''''749 '' 763 750 }}} 764 751 1. Quelle est la fonction du noyau qui appelle cette fonction et dans quel fichier? 765 752 {{{#!protected ------------------------------------------------------------------------------------ 766 '' '''''''''''''753 '' 767 754 - C'est la fonction `kinit()`, dans le fichier `kernel/kinit.c`. 768 '' '''''''''''''755 '' 769 756 }}} 770 757 1. Comment le noyau fait-il pour démarrer l'application en mode `kernel`? (la réponse est dans la fonction de la question précédente). 771 758 {{{#!protected ------------------------------------------------------------------------------------ 772 '' '''''''''''''773 - Dans la fonction `kinit()` : ligne 19, on initialise le bit `UM` du registre status `c0_sr` avec `0`. Ainsi, après l'exécution de `eret`, nous serons en mode `kernel`.759 '' 760 - Dans la fonction `kinit()`, on appelle `app_load(&_start)`, c'est une fonction écrite en assembleur, donc forcément dans `hcpua.S`. Dans cette fonction on initialise `c0_epc` avec l'adresse de `_start()`, on initialise le bit `UM` du registre status `c0_sr` avec `0`. Ainsi, après l'exécution de `eret`, nous serons en mode `kernel`. 774 761 {{{#!c 775 18 // this code allows to exit the kernel to go to user code 776 19 __asm__ volatile ( "la $26, __text_origin \n" // get first address ofuser code777 20 "mtc0 $26, $14 \n" // put it in c0_EPC 778 21 "li $26, 0b00000010 \n" // next status [UM,0,ERL,EXL,IE] 779 22 "mtc0 $26, $12 \n" // UM <- 0, IE <- 0, EXL <- 1 780 23 "la $29, __data_end \n" // define new user stack pointer 781 24 "eret \n");// j EPC and EXL <- 0782 }}} 783 '' '''''''''''''762 .globl app_load // ----------------- void app_load (void * fun) called by kinit() 763 app_load: // call when we exit kinit() function to go to user code 764 765 mtc0 $4, $14 // put _start address in c0_EPC 766 li $26, 2 // define next status reg. value 767 mtc0 $26, $12 // UM <- 0, IE <- 0, EXL <- 1 768 eret // j EPC and EXL <- 0 769 }}} 770 '' 784 771 }}} 785 772 … … 834 821 835 822 836 1. Dans quel fichier se trouve la définition des numéros de services tels que `SYSCALL_EXIT` ? 837 {{{#!protected ------------------------------------------------------------------------------------ 838 '' '''''''''''''823 1. Dans quel fichier se trouve la définition des numéros de services tels que `SYSCALL_EXIT` ? (''Ces numéros sont communs au noyau et à l'application'') 824 {{{#!protected ------------------------------------------------------------------------------------ 825 '' 839 826 - Ils sont dans le fichier `common/syscall.h`. 840 '' '''''''''''''827 '' 841 828 }}} 842 829 1. Dans quel fichier se trouve le vecteur de syscall, c'est-à-dire le tableau `syscall_vector[]` contenant les pointeurs sur les fonctions qui réalisent les services correspondants aux syscall ? 843 830 {{{#!protected ------------------------------------------------------------------------------------ 844 '' '''''''''''''831 '' 845 832 - Il est dans le fichier `kernel/ksyscall.c`. 846 '' '''''''''''''847 }}} 848 1. Dans quel fichier se trouve le gestionnaire de syscalls ? 849 {{{#!protected ------------------------------------------------------------------------------------ 850 '' '''''''''''''833 '' 834 }}} 835 1. Dans quel fichier se trouve le gestionnaire de syscalls ? (''c'est de l'assembleur'') 836 {{{#!protected ------------------------------------------------------------------------------------ 837 '' 851 838 - Il est dans le fichier `kernel/hcpua.S`. 852 '' '''''''''''''839 '' 853 840 }}} 854 841 … … 868 855 869 856 870 L'application utilisateur n'est pas censée utiliser directement les appels système. Elle utilise une librairie de fonctions standards (la `libc` POSIX, mais pas seulement) et ce sont ces fonctions qui réalisent les appels système. Toutes les fonctions de la `libc` n'utilisent pas les appels système. Par exemple, les fonctions `int rand(void)` ou `int strlen(char *)` (rendent, respectivement, un nombre pseudo aléatoire et la longueur d'une chaîne de caractères) n'ont pas besoin du noyau. Les librairies font partie du système d'exploitation mais elles ne sont pas dans le noyau.857 L'application utilisateur n'est pas censée utiliser directement les appels système. Elle utilise une librairie de fonctions standards (la `libc` POSIX, mais pas seulement) et ce sont ces fonctions qui réalisent les appels système. Toutes les fonctions de la `libc` n'utilisent pas les appels système. Par exemple, les fonctions `int rand(void)` ou `int strlen(char *)` (rendent, respectivement, un nombre pseudo aléatoire et la longueur d'une chaîne de caractères) n'ont pas besoin du noyau. Les librairies font partie du système d'exploitation mais elles ne sont pas dans le noyau. 871 858 872 859 ''Le terme « librairie » vient de l'anglais « library » qui signifie bibliothèque. On utilise souvent le mot librairie même si le sens en français n'est pas le même que celui en anglais. Disons que, dans notre contexte, les deux mots sont synonymes.'' … … 914 901 1. Pour ce petit système, dans quel fichier sont placés tous les prototypes des fonctions de la libc? Est-ce ainsi pour POSIX sur LINUX? 915 902 {{{#!protected ------------------------------------------------------------------------------------ 916 '' '''''''''''''903 '' 917 904 - Ils sont tous dans le fichier `libc.h`. 918 - Non, pour POSIX, les prototypes de fonctions de la libc sont répartis dans plusieurs fichiers suivant leur rôle. Il y `stdio.h`, `string.h`, `stdlib.h`, etc. Nous n'avons pas voulu ajouter cette complexité.919 '' '''''''''''''905 - Non, pour POSIX, les prototypes de fonctions de la libc sont répartis dans plusieurs fichiers suivant leur rôle. Il y a `stdio.h`, `string.h`, `stdlib.h`, etc. Nous n'avons pas voulu ajouter cette complexité. 906 '' 920 907 }}} 921 908 … … 925 912 926 913 - Vous allez juste ajouter la fonction `int cpuid()` dans la librairie `libc`. 927 - Au premier TP, vous deviez créer un petit jeu 'guess', vous pouvez en faire une application utilisateur, en utilisant cette fois les fonction de la `libc`.914 - Au premier TP, vous deviez créer un petit jeu 'guess', vous pouvez en faire une application utilisateur, en utilisant cette fois les fonctions de la `libc`.
