| 24 | | Définir : |
| 25 | | - segment physique |
| 26 | | - objet virtuel |
| 27 | | - segment virtuel |
| 28 | | - espace d'adressage virtuel |
| 29 | | - segments globaux |
| 30 | | - mapping d'un (ou plusieurs) vseg vers un pseg |
| | 25 | Le composant qui effectue cette traduction s'appelle la MMU (''Memory Management Unit''). La MMU a de plus une autre fonction, qui consiste à fournir un mécanisme de protection de la mémoire en vérifiant que les pages sont correctement accédées selon les attributs qui leur sont propres. Ces attributs sont principalement : |
| | 26 | * la page est inscriptible |
| | 27 | * la page est accessible en mode utilisateur |
| | 28 | * la page est exécutable (typiquement une page contenant du code) |
| | 29 | * la page est cachable |
| | 30 | D'autres attributs peuvent exister selon les architectures et systèmes d'exploitation. |
| 40 | | Commencez par récupérer l'archive de |
| | 39 | = 2. Présentation du mécanisme de mémoire virtuelle dans DSX = |
| | 40 | |
| | 41 | Au niveau de DSX, la notion de page est transparente. On définit un '''objet virtuel''' comme étant une partie indissociable de code ou données du programme initial qui est placée de manière contigüe en mémoire. Un objet virtuel peut par exemple être une section ELF ou un buffer. |
| | 42 | |
| | 43 | Un ou plusieurs objets virtuels sont regroupés dans un '''segment virtuel'''. Un segment virtuel est un espace contigü de l'espace d'adressage virtuel d'une application. Il contient (entre autres) une adresse de base et une taille. Certains segments virtuels sont spéciaux, car ils sont répliqués dans l'espace d'adressage de toutes les applications : on parle de '''segments globaux'''. Chaque segment virtuel est finalement placé sur un '''segment physique''', c'est-à-dire une zone de la mémoire physique contigüe ayant une adresse de base et une taille. Plusieurs segments virtuels peuvent bien sûr être placés sur le même segment physique. |
| | 44 | |
| | 45 | En plus d'effectuer le placement des objets logiciels sur les bancs mémoire, DSX permet par ailleurs d'effectuer le placement des tâches d'une application (définie comme un ensemble de tâches communiquantes par canaux MWMR) sur des processeurs donnés. Pour cela, DSX a besoin de connaitre un certain nombre d'information sur l'architecture sous-jacente (en plus des segments physiques). |
| | 46 | |
| | 47 | Cette description conjointe du matériel et du mapping se fait dans DSX par l'intermédiaire d'un format propre à cet outil utilisant le langage XML : la structure d'informations de mapping. Cette structure est défini en détail [[dsx:wiki:DsxvmMappingInfoStructure | ici]]. De plus, cette structure n'est pas parsée directement par le système d'exploitation, mais est transformée en structure binaire équivalente (basée sur des types C) par un petit outil appelé `xml2bin`, et placée dans le binaire final de l'application. Dans la suite, on parlera du fichier `map.xml` pour se référer au fichier xml contenant ces informations. |
| | 48 | |
| | 49 | Les informations contenues dans cette structure de données sont utilisées par le système d'exploitation (le giet-vm) pour construire la table des pages. La table des pages dans le giet-vm est statique (i.e. non modifiable pendant l'exécution) et sa construction a lieu lors de la phase de boot. |
| | 50 | |
| | 51 | Le schéma ci-dessous résume les différents objets manipulés par l'outil DSX : |
| | 52 | |
| | 53 | [[Image(structure_mapping_info.svg)]] |
| | 54 | |
| | 55 | Cette structure de mapping est soit donnée par l'utilisateur à DSX, soit produite par DSX à partir des informations concernant l'architecture et le mapping des tâches et objets logiciels. |
| | 56 | |
| | 57 | |
| | 58 | Après compilation par DSX des différentes applications et du giet-vm, on possède autant de fichiers binaires que d'application -- plus un pour le giet-vm -- contenant tous des adresses virtuelles. Ces adresses virtuelles doivent correspondre à celles utilisées dans manière arbitraire par le giet-vm si l'utilisateur fournit lui-même le fichier `map.xml` (pas sûr) (si le fichier `map.xml` est produit par DSX, il contient bien sûr des adresses cohérentes avec celles des binaires). Néanmoins se pose un problème pour le chargement du binaire en mémoire. En effet, le chargement s'effectue traditionnellement dans soclib avec un composant appelé `loader` qui charge les sections en mémoire à partir de leurs adresses dans le binaire. Comme ces adresses sont ici virtuelles, on ne peut pas procéder de la sorte directement. Deux solutions sont possibles : |
| | 59 | * Écrire un `vloader` qui utilise la structure `map.xml` et effectue la traduction lors du chargement. |
| | 60 | * Déplacer les sections pour obtenir un binaire avec les adresses de chargement. On peut ensuite utiliser le `loader` de soclib traditionnel. |
| | 61 | |
| | 62 | C'est cette dernière solution qui est retenue. Pour cela l'utilisation de DSX est couplée à un outil dont le nom est Memo² (MEMOry MErger and MOver). En plus d'effectuer le déplacement des sections à l'aide de la structure d'information de mapping, Memo² effectue aussi la fusion des différents binaires en un seul. |
| | 63 | |
| | 64 | Le schéma suivant montre une représentation simplifiée du fonctionnement de DSX : |
| | 65 | |
| | 66 | [[Image(dsxvm_overall_working.svg)]] |
| | 67 | |
| | 68 | |
| | 69 | = 3. Spécification des informations de mapping dans DSX = |
| | 70 | |
| | 71 | Nous allons pour commencer nous intéresser à l'application !SplitMsg vu au premier TP. Nous nous plaçons dans le cadre d'une plateforme contenant 1 seul cluster de 1 processeur. |
| | 72 | |
| | 73 | Commencez par récupérer l'archive suivante : |
| | 74 | |
| | 75 | |
| | 76 | |
| | 77 | |
| | 78 | Désassemblez le fichier `soft/split_msg/split_msg.elf` avec la commande : |
| | 79 | {{{ |
| | 80 | $ mipsel-unknown-elf-objdump -D soft/split_msg/split_msg.elf | less |
| | 81 | }}} |
| | 82 | |
| | 83 | '''''Question xx : Quelle est l'adresse de base de la fonction xxx ? Est-ce une adresse physique ou virtuelle ?''''' |
| | 84 | |
| | 85 | |
| | 86 | |
| | 87 | => Demander quelque part dans le TP pourquoi une seule passe pose problème (taille des binaires et de map.bin) |
| | 88 | |
| | 89 | |
| | 90 | |
| | 91 | |
