9 | | = 2 Architectures Clusterisées = |
| 9 | Le principal objectif de ce TP est d'introduire l'outil '''GDB Server''' qui permet de déverminer une application |
| 10 | logicielle embarquée s'exécutant sur une architecture matérielle prototypée avec SoCLib. |
| 11 | |
| 12 | = 2 Outil GDB Server = |
| 13 | |
| 14 | 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. |
| 15 | |
| 16 | Cet outil permet à un client GDB (voir [http://www.gnu.org/software/gdb/ 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. |
| 17 | La documentation de l'outil peut être consultée [https://www.soclib.fr/trac/dev/wiki/Tools/GdbServer ici]. |
| 18 | |
| 19 | Le GDB Server permet de: |
| 20 | * poser des points d'arrêt |
| 21 | * d'exécuter le programme en pas à pas |
| 22 | * de visualiser le contenu des registres de n'importe quel processeur |
| 23 | * de visualiser la valeur stockée à n'importe quelle adresse dans l'espace adressable |
| 24 | * de modifier le contenu de la mémoire ou d'un registre d'un processeur |
| 25 | |
| 26 | Le simulateur (qui contient le serveur GDB) et le client GDB peuvent s'exécuter sur deux stations de travail différentes, |
| 27 | puisque les communications entre le client GDB et le serveur GDB utilisent un canal TCP. |
| 28 | |
| 29 | == 2.1 Modification de la top-cell == |
| 30 | |
| 31 | Pour utiliser le '''GDB Server''', tous les processeurs dont on souhaite prendre le contrôle doivent être instanciés |
| 32 | dans un mode particulier lorsqu'on définit l'architecture de la '''top-cell'''. |
| 33 | Il faut remplacer l'instanciation habituelle du processeur: |
| 34 | {{{ |
| 35 | VciXcacheWrapper<Mips32ElIss> cpu0("cpu0", ...); |
| 36 | }}} |
| 37 | par une instanciation faisant appel au GDB Server |
| 38 | {{{ |
| 39 | VciXcacheWrapper<GdbServer<Mips32ElIss> > cpu0("cpu0", ...); |
| 40 | }}} |
| 41 | |
| 42 | Le GDB server est donc un pseudo-composant matériel, qui s'interface entre le processeur et le cache. |
| 43 | En prenant le contrôle du GDB Server (par l'intermédiaire du client GDB), on peut donc contrôler le processeur, |
| 44 | (pour le faire fonctionnner en pas à pas par exemple), et on peut également contrôler le reste du système |
| 45 | (en effectuant directement des commandes de lecture ou d'écriture vers les composants adressables). |
| 46 | |
| 47 | Il ne fautpas oublier d'inclurele "header" dans la top-cell |
| 48 | {{{ |
| 49 | #include "gdb_server.h" |
| 50 | }}} |
| 51 | |
| 52 | Il faut également complêter le fichier de description de l'architecture utilisé par soclib-cc (fichier platform.desc) : |
| 53 | {{{ |
| 54 | Uses('caba:iss_wrapper', iss_t = 'common:gdb_iss', gdb_iss_t = 'common:mips32el') |
| 55 | }}} |
| 56 | |
| 57 | == 2.2 lancement de la simulation == |
| 58 | |
| 59 | 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", |
| 60 | 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 : |
| 61 | {{{ |
| 62 | $ export SOCLIB_GDB=START_FROZEN |
| 63 | $ ./simulator.x |
| 64 | }}} |
| 65 | |
| 66 | 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: |
| 67 | {{{ |
| 68 | mipsel_unknown_elf_gdb soft/bin.soft |
| 69 | }}} |
| 70 | |
| 71 | La première commande à taper dans GDB est la commande permettant de connecter le client GDB au GDB Server: |
| 72 | {{{ |
| 73 | (gdb) target remote Localhost:2346 |
| 74 | }}} |
| 75 | |
| 76 | |
| 77 | == 2.1 Points d'arrêt == |
| 78 | |
| 79 | = 3 Architectures Clusterisées = |