Changes between Version 3 and Version 4 of SoclibCourseTp5

Timestamp:

Oct 19, 2009, 5:26:07 PM (16 years ago)

Author:

alain

Comment:

--

SoclibCourseTp5

@@ -1 +1 @@
 {{{
 #!html
-<h1>TP5 : Architectures multi-processeurs </h1>
+<h1>TP5 : GDB server </h1>
 }}}
 [[PageOutline]]
@@ -7 +7 @@
 = 1 Objectif =
 
-= 2 Architectures Clusterisées =
+Le principal objectif de ce TP est d'introduire l'outil '''GDB Server''' qui permet de déverminer une application
+logicielle embarquée s'exécutant sur une architecture matérielle prototypée avec SoCLib.
+
+= 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 [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.
+ La documentation de l'outil peut être consultée [https://www.soclib.fr/trac/dev/wiki/Tools/GdbServer ici].
+
+Le GDB Server permet de: 
+ * poser des points d'arrêt
+ * 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 d'un registre d'un processeur
+
+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'inclurele "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
+}}}
+
+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.1 Points d'arrêt ==
+
+= 3 Architectures Clusterisées =
 
 Nous appellerons ''architecture clusterisée'' une architecture dans laquelle on utilise un double système d'index