Transcript Développement UNIX en langage C Le C-UNIX

Développement C-UNIX
Développement UNIX en langage C
ISR-CSYS-02-001-01
Le C-UNIX
Chapitre 1/15 : malloc()
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Cadre générale de l’UV
Développement C-UNIX
Cadre générale de l’UV :
- ISR ou IDV? En principe cette UV concerne les deux
filière. Malgré cela, il apparaît qu’elle concerne plus
les étudiants inscrits en ISR puisque les concepts qui si
trouvent les toucheront plus dans leur vie de tout les
jour, même s’ils ne développent pas.
- Là encore, certains peuvent avoir déjà tout ou
partie de ces connaissances, il conviendra qu’il
s’assurent de ne pas passer à coté de cette UV pour
autant.
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Plan de l’UV
Développement C-UNIX
Plan de l’UV ISR-CSYS-02-001:
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ISR-CSYS-02-001-01
01/ malloc()
02/ Les signaux
03/ Les processus et le job control
04/ pipe / redirection
05/ Les devices
06/ Gestion des entrée/sorties avancées
07/ Gestion des terminaux
08/ mmap()
09/ Les threads
10/ Communication interprocessus
11/ Communication interprocessus avancée
12/ Le format elf
13/ Le file systeme /proc
14/ L’assembleur in-line
15/ Sécurité des développement en C-UNIX
Samir RINAZ © 2005 pour ETNA
Généralités sur la mémoire
Développement C-UNIX
• La mémoire est le moyen de sauvegarder
des informations. On entend par mémoire
centrale le support de l'information active
(système d'exploitation, tampons logiciels,
programmes en cours d'exécution),
mémoire cache le support de l'information
immédiate (tampons matériels) et mémoire
de masse le support de l'information à long
terme (disques, bandes magnétiques,
etc...).
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Mémoire centrale
Développement C-UNIX
• La memoire centrale, encore appelee RAM,
est le memoire de travail. Elle est
relativement rapide d'acces et le
processeur y accede continuellement. Plus
elle est grande, plus les programmes
s'executent de maniere fluide. D'un point de
vue materiel, elle se presente generalement
sous la forme d'une ou plusieurs barettes
que l'on fixe sur la carte mere. Aujourd'hui
son ordre de grandeur est le mega-octet.
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Mémoire cache
Développement C-UNIX
• La mémoire cache, encore appelée
antémémoire, est généralement de petite
taille, plus rapide d'accès que la mémoire
centrale et conserve les informations
susceptibles d'êtres utilisées plusieurs fois afin
de réduire les échangés entre le processeur
et la mémoire centrale (et les autres
périphériques). Elle se présente sous la forme
d'une puce sur la carte mère. Aujourd'hui
son ordre de grandeur est le kilo-octet.
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Mémoire de masse
Développement C-UNIX
• La mémoire de masse est de grande taille et son
rôle premier est de conserver les informations de
manière durable (fichiers). Elle peut être utilisée lors
d'un manque de mémoire centrale (ce mécanisme
s'appelle le swap) mais son temps d'accès étant
beaucoup plus lent, cela ralentit les performances
(les programmes s'exécutent de manière moins
fluide). Elle se présente sous la forme de disques,
disquettes, bandes magnétiques, cd, dvd, etc...
Aujourd'hui son ordre de grandeur est le giga-octet,
voir le tera-octet.
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
MMU
Développement C-UNIX
• Le MMU est une partie hardware (souvent intégrée au
processeur) qui est chargée de convertir les adresses virtuelles
en adresses physiques. Elle est généralement implémentée
sous la forme d'un cache appelé TLB (Translation Lookaside
Buffer). Unix à la possibilité d'effectuer diverses opérations
dans ce cache et intercepte toutes les erreurs du MMU
(adresses invalides, manquantes, etc). Par exemple, une
interruption relative a une adresse invalide va permettre au
kernel de poster un signal SIGSEGV au processus fautif.
• Les adresses virtuelles permettent de :
– Vérifier qu'un processus n'accède pas a une adresse physique
auquel il n'aurait pas droit (sécurité)
– Mapper (cartographier) la mémoire au bon vouloir du
programmeur.
Cartographier n'importer quel objet (fichier, périphérique, etc)
dans la mémoire.
• Note: Pour augmenter l'efficacité du "mapping", l'espace
d'adressage est découpé en pages (cela évite d'avoir une
entrée par adresse dans le TLB). Voir getpagesize(2).
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Mémoire d'un processus
Développement C-UNIX
• Sur un système dit "32 bits", la mémoire virtuelle s'étend de 0 à
232 soit à peu près 4 milliards d'octets. Dans cet immense
espace, une partie est réservée pour le kernel, l'autre est
réservée à l'espace utilisateur.
• Le kernel prépare au moins trois zones à l'avance pour le
processus dans son espace utilisateur:
• Une zone de texte où est logé le code exécutable
(normalement protégée en écriture).
• Une zone de données (data) qui contient d'une part les
données statiques (variables initialisées dans le fichier
exécutable) d'autre part les données dynamiques (appelée
tas).
• Une zone de pile (stack en anglais) contenant les variables
locales et les paramètres des fonctions. Nous remarquons qu'il
reste une immense zone vide disponible: 0xefbfe000 =
4022329344 octets moins la taille des zones de pile, de data et
de texte, soit près de 4Go.
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Mémoire d'un processus, schéma
Développement C-UNIX
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Mémoire utilisée par un processus
Développement C-UNIX
• Il est possible de connaitre la mémoire
utilisée par un processus grâce a la
commande ps(1) avec l'option m. Un
certain nombre de champs
d'informations sont disponibles mais
sont dépendants du type de gestion
mémoire (nombre de pages logiques
utilisées, etc). Le champ SIZE
corresponds a la taille de la mémoire
en kilo-octets.
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Mémoire disponible pour un processus
Développement C-UNIX
• Etant donne que la limite mémoire est un attribut du
processus et que les attributs sont hérites (voir
time(1)), héritage, limites de processus), elle est
celle de son père qui est dans la plupart des cas un
shell. Chacun des différents shells dispose d'une
commande intégrée qui, avec l'option adéquate,
permet de la visualiser ; pour la famille sh(1), il s'agit
de ulimit, pour la famille des csh(1) il s'agit de
« limit ».
• De manière générale, la mémoire disponible est
suffisante pour la plupart des programmes
correctement analyses. Toutefois il est possible de
faire modifier cette limite par l'administrateur.
(getrusage(2), getrlimit(2), wait(2)).
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Fonctions et appels systèmes mis en jeux
Développement C-UNIX
• brk() et sbrk():
SYNOPSIS
#include <unistd.h>
int
brk(void *addr);
void *
sbrk(intptr_t incr);
• Ces fonctions servent à déplacer la limite du
segment data. (voir schéma précédent).
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Comment ca marche malloc?
Développement C-UNIX
• Déplacer la limite du segment data est bien beau, ceci ne dit
pas comment malloc() parvient à allouer de la mémoire.
• En fait, ici, on a la zone mémoire effectivement allouée par le
système pour le processus qui varie. Il faut encore que
malloc() « gère » cette zone.
• Pour ce faire, il n’y a qu’une solution : faire des sous espaces
de cette ensemble afin de stocker ce que nécessaire pour
chaque invocation.
• Il devra travailler en relation avec free() pour éviter les
fragmentation de cet espace.
• Il existe un très grand nombre de façon de le faire. De façon à
être plus ou moins performant / économe en espace
mémoire.
• La solution la plus simple est de délimiter les sous ensembles
par des structures de données que l’on utilisera pour indiquer
taille de la zone, adresse de la zone suivante et tout autre
éléments utiles. On appel cette structure le descripteur de
block.
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Comment ca marche, schéma
Développement C-UNIX
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA
Conclusion
Développement C-UNIX
• Vous avez ici bon nombre de éléments
constituant le fonctionnement de
malloc(), vous allez être à même de le
recoder, vous allez faire my_malloc()!
• Pour la suite, le prochain cours est
« Les signaux »
ISR-CSYS-02-001-01
Samir RINAZ © 2005 pour ETNA