Version 7 (modified by 15 years ago) (diff) | ,
---|
TP5 : GDB server
1 Objectifs
Ce TP possède un double objectif. D'un côté, on présente l'outil GDB Server qui est pratiquement indispensable pour déverminer une application logicielle embarquée s'exécutant sur une architecture matérielle prototypée avec SoCLib. D'autre part, et puisque l'outil GDB Server permet d'analyser le comportement d'architectures multiprocesseurs, on en profiter pour introduire les architectures clusterisées utilisant deux niveaux d'indexation.
2 Outil GDB Server
L'outil GDB Server permet d'analyser finement le comportement d'une application logicielle multi-threads s'exécutant sur une architecture matérielle multi-processeur modélisée avec SoCLib.
Cet outil permet à un client GDB (voir Gnu GDB) s'exécutant sur n'importe quelle station de travail de prendre le contrôle du simulateur d'une plate-forme matérielle modélisée avec SoCLib.
La documentation de l'outil GDB Server peut être consultée ici.
Le GDB Server permet de:
- poser des points d'arrêt dans le programme en cours d'exécution
- d'exécuter le programme en pas à pas
- de visualiser le contenu des registres de n'importe quel processeur
- de visualiser la valeur stockée à n'importe quelle adresse dans l'espace adressable
- de modifier le contenu de la mémoire ou des registres des processeurs
Le simulateur (qui contient le serveur GDB) et le client GDB peuvent s'exécuter sur deux stations de travail différentes, puisque les communications entre le client GDB et le serveur GDB utilisent un canal TCP.
2.1 Modification de la top-cell
Pour utiliser le GDB Server, tous les processeurs dont on souhaite prendre le contrôle doivent être instanciés dans un mode particulier lorsqu'on définit l'architecture de la top-cell. Il faut remplacer l'instanciation habituelle du processeur:
VciXcacheWrapper<Mips32ElIss> cpu0("cpu0", ...);
par une instanciation faisant appel au GDB Server
VciXcacheWrapper<GdbServer<Mips32ElIss> > cpu0("cpu0", ...);
Le GDB server est donc un pseudo-composant matériel, qui s'interface entre le processeur et le cache. En prenant le contrôle du GDB Server (par l'intermédiaire du client GDB), on peut donc contrôler le processeur, (pour le faire fonctionnner en pas à pas par exemple), et on peut également contrôler le reste du système (en effectuant directement des commandes de lecture ou d'écriture vers les composants adressables).
Il ne fautpas oublier d'inclure le "header" dans la top-cell
#include "gdb_server.h"
Il faut également complêter le fichier de description de l'architecture utilisé par soclib-cc (fichier platform.desc) :
Uses('caba:iss_wrapper', iss_t = 'common:gdb_iss', gdb_iss_t = 'common:mips32el')
2.2 lancement de la simulation
Pour utiliser GDB Server, il est généralement préférable de lancer le simulateur dans un mode où la plate-forme est "gelée", et attend une commande du GDB Server. Cela peut être réalisé en définissant la variable d'environnement SOCLIB_GDB avant de lancer le simulateur :
$ export SOCLIB_GDB=START_FROZEN $ ./simulator.x
2.3 lancement du client GDB
Une fois que le simulateur est lancé, il faut lancer (dans une autre fenêtre), l'exécution du client GDB adapté au type de processeur instancié dans la plate-forme, en lui passant en argument le nom du fichier contenant le code binaire exécuté par les processeurs de l'architecture. Pour un processeur MIPS32:
mipsel_unknown_elf_gdb soft/bin.soft
La première commande à taper dans GDB est la commande permettant de connecter le client GDB au GDB Server:
(gdb) target remote Localhost:2346
2.4 identification des processeurs
L'outil GDB standard permet par d'analyser le comportement d'applications multi-threads s'exécutant sur une architecture monoprocesseur. Nous souhaitons ici contrôler une architecture multi-processeurs. Pour pouvoir re-utiliser le client GDB standard, le GDB Server considère chaque processeur comme une thread. Pour obtenir le nombre de processeurs contrôlables par GDB, il faut taper la commande :
(gdb) info threads
Attention : la numérotation des threads ne correspond pas nécessairement à la numérotation des processors (proc_id)
2.5 Points d'arrêt
La commande break (br) permet de poser des points d'arrêt correspondant à la détection d'une adresse particulière dans le registre PC d'un processeur quelconque de l'architecture simulée :
(gdb) br *0x8000180
Dans ce cas, tous les processeurs de la plate-forme s'arrêtent simultanément.
On peut également utiliser un nom de fonction plutôt qu'une adresse hexadécimale
(gdb) br function_name
2.6 Exécution
Lorsque l'exécution est arrété, la commande continue (c) permet de relancer l'exécution jusqu'au prochain point d'arrêt. Tous les processeurs reprennent leur exécution.
(gdb) c
La commande stepi permet de relancer l'exécution d'une seule instruction assembleur. Seul le processeur qui a détecté un point d'arrêt est concerné. Les autres processeurs restent bloqués:
(gdb) stepi
2.7 Observation des registres
La commande info permet d'afficher différentes informations.
(gdb) info
Sans argument cette commande donne la liste des informations disponibles.
(gdb) info reg
Avec l'argument reg, elle affiche le contenu des registres du processeur qui a détecté un point d'arrêt. Si on veut observer les valeurs contenues dans les registres d'un autre processeur, il faut préalablement utiliser la commande thread n (où n est le numéro de la thread représentant le processeur.
(gdb) thread n (gdb) info reg
2.8 Observation/modification de la mémoire
Pour observer les valeurs contenues en mémoire, on peut utiliser la commande examine (x) :
(gdb) x/10x 0x400000
Cette commande va afficher en hexadécimal 10 mots de 32 bits à partir de l'adresse 0x400000.
Pour modifier une valeur en mémoire, on peut utiliser la commande set :
(gdb) set *(int*)0x400000 = val
Cette commande écrit la valeur val (de type int) à l'adresse 0x400000.
3 Architectures Clusterisées
Nous appellerons architecture clusterisée une architecture dans laquelle on utilise un double système d'index
pour repérer les initiateurs et les cibles VCI. Un cluster est un sous-système regroupant généralement plusieurs
initiateurs et plusieurs cibles VCI, communiquant entre eux par un interconnect local (bus ou crossbar).
Chaque composant est donc repèré par un couple (cluster_index, local_index)
.
L'espace d'adressage reste partagé par tous les composants du système (quel que soit leur cluster), et n'importe quel initiateur peut directement adresser n'importe quelle cible. Si l'initiateur et la cible n'appartiennent pas au même cluster, les paquets VCI (commande et réponse) sont acheminés grace à un interconnect global (généralement un micro-réseau intégré ou NoC).
Ce regroupement en clusters répond généralement à deux objectifs:
- D'un point de vue architecture, regrouper dans un même cluster les composants qui communiquent beaucoup entre eux permet de réduire la latence des communications, et de minimiser la consommation. Ce découpage permet également de distribuer la mémoire embarquée, et d'éviter le goulot d'étranglement que constituerait un unique banc mémoire sur la puce (même si l'accès à la mémoire externe reste un goulot d'étranglement).
- D'un point de vue électrique, le découpage en clusters permet de résoudre en partie les problèmes d'horlogerie, puisque chaque cluster peut être implanté dans un domaine d'horloge séparé (approche GALS : Globally Asynchronous / Locally Synchronous). Le franchissement des frontières d'horlogre est alors la responsabilité du micro-réseau assurant les communications inter-clusters.
Pour faciliter le décodage des adresses, on décompose les bits de poids fort de l'adresse VCI en deux champs GADR et LADR, de telle sorte que le décodage du champs GADR définisse complêtement le numéro du cluster cible. Le décodage du champs LADR permet lui de déterminer l'index local de la cible dans un cluster. Le nombre de bits des champs GADR et LADR dépend évidemment du système.
GADR | LADR | OFFSET |
Cette organisation hiérarchique à deux niveaux impose évidemment que les valeurs des champs GADR des segments associés aux cibles d'un même cluster soient égales entre elles (ou appartiennent à un même ensemble de valeurs caractéristiques de ce cluster)
Attachments (4)
- soclib_tp5_gdb_server.png (37.3 KB) - added by 14 years ago.
- soclib_tp5_transpose.png (19.8 KB) - added by 14 years ago.
- soclib_tp5_archi_clusters.png (36.6 KB) - added by 11 years ago.
- soclib_tp5.tgz (241.9 KB) - added by 11 years ago.
Download all attachments as: .zip