Files
BUT2/TP_SCR3.1/TP_Memoire/tp-reponses-yolou.txt

180 lines
7.9 KiB
Plaintext

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 <piud>, 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