changement du fichier tp scr
This commit is contained in:
180
TP_SCR3.1/TP_Memoire/tp-reponses-yolou.txt
Normal file
180
TP_SCR3.1/TP_Memoire/tp-reponses-yolou.txt
Normal file
@@ -0,0 +1,180 @@
|
||||
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
|
||||
Reference in New Issue
Block a user