TP1 MEMOIRE - YOLOU 1. Ce que je dois comprendre sur le code le processus possède une mémoire qui contient des adresses virtuelles vdsco ce sont des appels systeme y'en a que 4 get of day c'est un appel systeme, le prgramme considere que c'est un appel systeme mais ca n'utilise pas l'organisation du noyaux (sauvegarde, rechargement etc...) [yolou@salle223-10 TP_Memoire]$ ./a.out je suis le pid 23540 main = 0x559308d20179 gettimeofday = 0x7f08d7032870 &argc = 0x7ffd6bca825c &i = 0x7ffd6bca826c &j = 0x559308d24000 t = 0x559308d23060 m = 0x559320a82310 ^Z [1]+ Stopped ./a.out [yolou@salle223-10 TP_Memoire]$ cat /proc/23540/maps adresse début adresse fin perms offset devices inode chemin 559308d1f000-559308d20000 r--p 00000000 00:3e (périphèrique) 70729069 /export/home/info-but24/yolou/BUT2/TP_SCR/TP_Memoire/a.out 559308d20000-559308d21000 r-xp 00001000 00:3e 70729069 /export/home/info-but24/yolou/BUT2/TP_SCR/TP_Memoire/a.out 559308d21000-559308d22000 r--p 00002000 00:3e 70729069 /export/home/info-but24/yolou/BUT2/TP_SCR/TP_Memoire/a.out 559308d22000-559308d23000 r--p 00002000 00:3e 70729069 /export/home/info-but24/yolou/BUT2/TP_SCR/TP_Memoire/a.out 559308d23000-559308d25000 rw-p 00003000 00:3e 70729069 /export/home/info-but24/yolou/BUT2/TP_SCR/TP_Memoire/a.out 559320a82000-559320aa3000 rw-p 00000000 00:00 0 [heap] 7f08d6c00000-7f08d6c24000 r--p 00000000 103:05 6028 /usr/lib/libc.so.6 7f08d6c24000-7f08d6d96000 r-xp 00024000 103:05 6028 /usr/lib/libc.so.6 7f08d6d96000-7f08d6e05000 r--p 00196000 103:05 6028 /usr/lib/libc.so.6 7f08d6e05000-7f08d6e09000 r--p 00204000 103:05 6028 /usr/lib/libc.so.6 7f08d6e09000-7f08d6e0b000 rw-p 00208000 103:05 6028 /usr/lib/libc.so.6 7f08d6e0b000-7f08d6e13000 rw-p 00000000 00:00 0 7f08d6ffb000-7f08d7000000 rw-p 00000000 00:00 0 7f08d702c000-7f08d7030000 r--p 00000000 00:00 0 [vvar] 7f08d7030000-7f08d7032000 r--p 00000000 00:00 0 [vvar_vclock] 7f08d7032000-7f08d7034000 r-xp 00000000 00:00 0 [vdso] 7f08d7034000-7f08d7035000 r--p 00000000 103:05 6019 /usr/lib/ld-linux-x86-64.so.2 (=> mappage dans le disque dur, quand on invoque le printf etc c'est ici qu'il vient ressourcer) 7f08d7035000-7f08d705f000 r-xp 00001000 103:05 6019 /usr/lib/ld-linux-x86-64.so.2 7f08d705f000-7f08d706d000 r--p 0002b000 103:05 6019 /usr/lib/ld-linux-x86-64.so.2 7f08d706d000-7f08d706f000 r--p 00039000 103:05 6019 /usr/lib/ld-linux-x86-64.so.2 7f08d706f000-7f08d7070000 rw-p 0003b000 103:05 6019 /usr/lib/ld-linux-x86-64.so.2 7f08d7070000-7f08d7071000 rw-p 00000000 00:00 0 7ffd6bc89000-7ffd6bcaa000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Bibliotheque dynamique dln windows / Bibl. standard C libsc : . La libc contient les fonctions comme printf, malloc, exit... . PLusieurs segment comme : . r-xp = code éxécutable de la bibliothèque . r-p = données en lecture seule . rw-p = données globales de la libc. [vvar] : . Virtual Variables : zone créée par le noyau pour partager certaines infos comme l'horloge entre le noyau et ton programme . Lecture seule. id-linux (linker dynamique) : Le chargeur dynamique : c'est lui qui charge les biblio partagé comme libc en mémoire Il est obligatoire pour éxécuter un programme avec des bibliothèques dynamiques [stack] (pile) : La pile du processus Sert a stocker : variable locales, adresse de retour des fonctions, parametres. Grandit quand tu appelles des fonctions imbriquées. Adresse-debut/fin = adresses virtuelles il y a les perms : r-xp = lecture + execution -> segment code r-p = lecture seul -> constantes rw-p = lecture/écriture -> variables globales initialisées Virtual Dymanic Shared Object => Petite zone pour accelerer certains appels systeme (ex gettimeofday) = vsdo Heap(tas) : . zone utilisée pour les allocations dynamiques(malloc,callocfree) . grandit ou rétrécit selon les besoins. 2) Apres avoir fait la commande pmap -x , j'observe que il y'a plusieurs adresses : Addresss -> l'adresse virtuelle oû commence ce segment mémoire Kbytes -> taille totale du segments (réservée) RSS (Resident Set Size) -> combien de mémoire de ce segment est réellement physqiuement en RAM (le reste peut etre sur disque ou pas encore utilisé) pour savoir si elle sont mappé physiquement Dirty -> nombre de Kilo octet modifiés (non partagés, spécifiques à mon processus) Mode -> permission du segment : r, w, x, s ou p : partagé (shared) ou prié (private) Mapping -> d'oû vient ce segment (exécutable a.out, biblliothèque, [stack], [heap], [anone] pour anonyme) Typiquement avec le prgramme du premier exo : 113416: ./a.out Address Kbytes RSS Dirty Mode Mapping 000055c06db68000 4 4 0 r---- a.out 000055c06db69000 4 4 0 r-x-- a.out 000055c06db6a000 4 4 0 r---- a.out 000055c06db6b000 4 4 4 r---- a.out 000055c06db6c000 8 8 8 rw--- a.out 000055c091c49000 132 4 4 rw--- [ anon ] 00007f0f90000000 144 144 0 r---- libc.so.6 00007f0f90024000 1480 1060 0 r-x-- libc.so.6 00007f0f90196000 444 128 0 r---- libc.so.6 00007f0f90205000 16 16 16 r---- libc.so.6 00007f0f90209000 8 8 8 rw--- libc.so.6 00007f0f9020b000 32 20 20 rw--- [ anon ] 00007f0f903f9000 20 12 12 rw--- [ anon ] 00007f0f9042b000 16 0 0 r---- [ anon ] 00007f0f9042f000 8 0 0 r---- [ anon ] 00007f0f90431000 8 8 0 r-x-- [ anon ] 00007f0f90433000 4 4 0 r---- ld-linux-x86-64.so.2 00007f0f90434000 168 168 0 r-x-- ld-linux-x86-64.so.2 00007f0f9045e000 56 56 0 r---- ld-linux-x86-64.so.2 00007f0f9046c000 8 8 8 r---- ld-linux-x86-64.so.2 00007f0f9046e000 4 4 4 rw--- ld-linux-x86-64.so.2 00007f0f9046f000 4 4 4 rw--- [ anon ] 00007ffc6a1a9000 132 12 12 rw--- [ stack ] ffffffffff600000 4 0 0 --x-- [ anon ] ---------------- ------- ------- ------- total kB 2712 1680 100 1. a.out (mon prgm) Aplusieurs lignes avec a.out : r-x -> segment code exécutable r-- -> données en lecture seule (constates) rw- -> données globales modifiables 2. [anone] (anonyme) Memoire réservée par le processus sans fichier associé Ici ca peut etre des petit malloc 3. libc.so.6 La bibliothèque standard du C (printf,malloc, ...). .r-x -> code éxécutable de la libc . rw- -> données de la libc 4. Id-linux x86-64.so.2 Le chargeur dynamique qui charge les bibliothèque Lui aussi a code (r-x) et données (rw-). total kB : 2712 Le processus occupe environ 2.7 Mo au total. Sur ces 2712 Ko, 1680 Ko sont effectivement en RAM (RSS). Le reste peut etre reservé mais pas encore utilisé. Généralement, le programme est découpé en segments mémoire : code, données, heap, pile, bibliothéques, mappings, anonymes. La commande pmap -x permet de voir : combien est réservé (Kbvtes) le processus, cobmien est vraiment en RAM (RSS), combien est spécifique au processus (Dirty) et pour finir l'origine du segment (Mapping) Ca illustre le cours le cours sur l'organisation mémoire d'un processus et la gestion par Linux via mémoire vituelle + MMU (MMU pour memory management unit), un composant informatique responsable de l'accès à la mémoire demandée par le processeur). Pour le code buf : Pour les segments "buf" (l'executable) Plusierus petites lignes de 4kB avec buf : r-x -> code éxécutable