RFC-909 |
Christopher Welles, BBN Communications Corporation |
Catégorie : Expérimentale |
Walter Milliken, BBN Laboratories |
Traduction Claude Brière de L'Isle |
juillet 1984 |
Protocole de débogage de chargement
Statut du présent mémoire
Cette RFC spécifie une proposition de protocole pour la communauté ARPA Internet, et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.
Table des matières
1.2 Résumé des caractéristiques
2.2 Relation aux autres protocoles
2.2.1 Exigences du service de transport
3. Fonctionnement du protocole
3.4 Mise en paquet et transmission des données
5.8 Accusé de réception ERRACK
6 Commandes de transfert de données
6.9 Commande WRITE_MASK (facultative)
9 Points de coupure et points d'observation
10.1 Format de commande Condition
11 Commandes de point de coupure
APPENDICE A Conventions pour les diagrammes
APPENDICE B Sommaire des commandes
APPENDICE C Commandes, réponses et répliques
Table des figures
Figure 1 : Relation avec les autres protocoles .......................................................................................................................................... 5
Figure 2 : Forme de l'échange des données entre les couches .............................................................................................................. 6
Figure 3 : Mise en paquet de mots de 16 bits ........................................................................................................................................... 7
Figure 4 : Mise en paquet de mots de 20 bits ........................................................................................................................................... 7
Figure 5 : Format de paquet réseau ............................................................................................................................................................ 8
Figure 6 : Format d'en-tête de commande LDP ......................................................................................................................................... 9
Figure 7 : Classes de commandes ............................................................................................................................................................... 9
Figure 8 : Types de commande ................................................................................................................................................................. 10
Figure 9 : Format d'adresse long ............................................................................................................................................................... 11
Figure 10 : Modes d'adresse longue ........................................................................................................................................................ 11
Figure 11 : Format d'adresse court ............................................................................................................................................................ 13
Figure 12 : Modes d'adresse courts ......................................................................................................................................................... 14
Figure 13 : Format de la commande HELLO ............................................................................................................................................ 14
Figure 14 : Format de HELLO_REPLY ...................................................................................................................................................... 15
Figure 15 : Types de système .................................................................................................................................................................... 15
Figure 16 : Codes d'adresse cible .............................................................................................................................................................. 15
Figure 17 : Niveaux de caractéristiques ................................................................................................................................................... 15
Figure 18 : Options ...................................................................................................................................................................................... 16
Figure 19 : Format de la commande SYNCH ............................................................................................................................................ 16
Figure 20 : Format de SYNCH_REPLY ..................................................................................................................................................... 16
Figure 21 : Format de la commande ABORT ........................................................................................................................................... 17
Figure 22 : Format de réplique ABORT_DONE ...................................................................................................................................... 17
Figure 23 : Format de la réplique ERROR ................................................................................................................................................. 18
Figure 24 : Codes d'erreur .......................................................................................................................................................................... 18
Figure 25 : Format de commande ERRACK ............................................................................................................................................. 19
Figure 26 : Format de la commande WRITE ............................................................................................................................................ 20
Figure 27 : Format de la commande READ .............................................................................................................................................. 21
Figure 28 : Format de réponse de DATA ................................................................................................................................................ 21
Figure 29 : Format de la réplique READ_DONE ..................................................................................................................................... 22
Figure 30 : Format de la commande MOVE ............................................................................................................................................. 23
Figure 31 : Format de réponse MOVE_DATA ....................................................................................................................................... 24
Figure 32 : Formatde la réplique MOVE_DONE ..................................................................................................................................... 24
Figure 33 : Format de la commande REPEAT_DATA ........................................................................................................................... 25
Figure 34 : Format de WRITE_MASK ..................................................................................................................................................... 26
Figure 35 : Format de la commande START ............................................................................................................................................ 27
Figure 36 : Format de la commande STOP ............................................................................................................................................... 28
Figure 37 : Format de la commande CONTINUE .................................................................................................................................... 28
Figure 38 : Format de la commande STEP ................................................................................................................................................ 29
Figure 39 : Format de la commande REPORT .......................................................................................................................................... 29
Figure 40 : Format de réplique STATUS .................................................................................................................................................. 30
Figure 41 : Format de EXCEPTION ........................................................................................................................................................... 31
Figure 42 : Format de la commande CREATE ......................................................................................................................................... 31
Figure 43 : Types créés .............................................................................................................................................................................. 32
Figure 44 : Format de CREATE BREAKPOINT ...................................................................................................................................... 32
Figure 45 : Format de CREATE MEMORY_OBJECT ............................................................................................................................ 33
Figure 46 : Format de réplique CREATE_DONE .................................................................................................................................... 33
Figure 47 : Format de la commande DELETE .......................................................................................................................................... 34
Figure 48 : Format de réplique DELETE_DONE ..................................................................................................................................... 34
Figure 49 : Format de la commande LIST_ADDRESSES ....................................................................................................................... 35
Figure 50 : Format de réplique ADDRESS_LIST .................................................................................................................................... 36
Figure 51 : Format de la commande LIST_BREAKPOINTS .................................................................................................................. 36
Figure 52 : Format de réplique BREAKPOINT_LIST ............................................................................................................................. 37
Figure 53 : Format de la commande LIST_PROCESSES ........................................................................................................................ 37
Figure 54 : Format de réplique PROCESS_LIST ..................................................................................................................................... 38
Figure 55 : Format de la commande LIST_NAMES ............................................................................................................................... 39
Figure 56 : Format de réplique NAME_LIST .......................................................................................................................................... 39
Figure 57 : Format de la commande GET_PHYS_ADDR ....................................................................................................................... 40
Figure 58 : Format de réplique GOT_PHYS_ADDR ............................................................................................................................... 41
Figure 59 : Format de la commande GET_OBJECT ................................................................................................................................ 41
Figure 60 : Format de réplique GOT_OBJECT ........................................................................................................................................ 42
Figure 61 : Commandes pour manipuler les points de coupure ........................................................................................................... 42
Figure 62 : Listes de commandes conditionnelles de point de coupure ............................................................................................. 43
Figure 63 : Format de commande BREAKPOINT_DATA .................................................................................................................... 44
Figure 64 : Format de flux de données de point de coupure ................................................................................................................. 44
Figure 65 : Résumé des commandes conditionnelles ............................................................................................................................ 45
Figure 66 : En-tête de la commande Condition ....................................................................................................................................... 46
Figure 67 : Format de la condition COUNT ............................................................................................................................................. 46
Figure 68 : Condition CHANGED ............................................................................................................................................................. 47
Figure 69 : Condition COMPARE ............................................................................................................................................................. 47
Figure 70 : Condition TEST ....................................................................................................................................................................... 48
Figure 71 : Résumé des commandes de point de coupure .................................................................................................................... 49
Figure 72 : Format de la commande INCREMENT ................................................................................................................................. 49
Figure 73 : Format de la commande INC_COUNT .................................................................................................................................. 49
Figure 74 : Format de la commande OR .................................................................................................................................................... 50
Figure 75 : Format de la commande SET_PTR ........................................................................................................................................ 50
Figure 76 : Format de la commande SET_STATE .................................................................................................................................. 51
Figure 77 : Diagramme exemple ................................................................................................................................................................. 51
Figure 78 : Sommaire des commandes ...................................................................................................................................................... 52
Figure 79 : Commandes, réponses et répliques ...................................................................................................................................... 52
Le protocole de débogage de chargement (LDP, Loader-Debugger Protocol) est un protocole de couche d'application pour le chargement, le déchargement et le débogage de machines cibles à partir des hôtes dans un environnement de réseau. Ce protocole est conçu pour s'accommoder de divers types de cpu cibles. Il fournit un ensemble de puissants services de débogage. En même temps, il est structuré de telle sorte qu'un simple sous-ensemble puisse en être mis en œuvre dans des applications telles que le chargement d'amorçage lorsque l'efficacité et l'espace sont surtout recherchés.
Les auteurs remercient Dan Franklin et Peter Cudhea qui ont fourni beaucoup des idées sur lesquelles se fonde ce protocole.
Il s'agit d'une spécification technique du protocole LDP. Elle est destinée à être suffisamment exhaustive pour qu'elle puisse être utilisée pour la mise en œuvre du protocole. Elle contient des descriptions détaillées des formats et usages de plus de quarante commandes. Les lecteurs intéressés par un survol de LDP pourront lire le Résumé des caractéristiques ci-dessous, et sauter les paragraphes 2 à 3.1. Voir aussi à l'Appendice B, le sommaire des commandes. Le reste du document se lit mieux accompagné de café ou thé fort.
1.2 Résumé des caractéristiques
LDP a les caractéristiques suivantes :
o des commandes pour effectuer le chargement, le déchargement et le débogage
o les prises en charge de connexions multiples sur une seule cible
o des performances fiables dans un environnement internet
o un petit sous-ensemble du protocole pour les chargeurs cibles
o des modes et commandes d'adressage pour prendre en charge plusieurs types de machine
o des points de coupure et des points d'observation qui entrent dans la machine cible.
LDP est un protocole d'application qui fournit un ensemble de commandes utilisées par les programmes d'application pour charger, décharger et déboguer les machines cibles à travers un réseau.
Les objectifs de ce protocole sont décrits par la liste suivante :
o Le protocole devrait prendre en charge divers types de processeurs et de systèmes d'exploitation. Les redondances et la complexité devraient être minimisées pour les cas les plus simples.
o Le protocole devrait prendre en charge des applications dans lesquelles plus d'un utilisateur peut déboguer la même machine cible. Cela implique qu'un mécanisme de transport sous-jacent prenne en charge plusieurs connexions entre une paire hôte-cible.
o LDP devrait avoir un ensemble minimal de commandes pour le chargement et le déchargement d'amorçage. Les mises en œuvre de machine cible de ces applications sont souvent restreintes quant à la quantité d'espace de code qu'elles peuvent prendre. Les services nécessaires pour le chargement et le déchargement devraient être fournis dans un petit ensemble de commandes faciles à mettre en œuvre.
o Il devrait y avoir un moyen pour communiquer les exceptions et erreurs de processus LDP cible au processus d'hôte.
o LDP devrait permettre à l'application de mettre en œuvre un ensemble complet de fonctions de débogage sans sanctionner les performances de l'application cible (c'est-à-dire., PSN, PAD, routeurs).
Par exemple, un mécanisme de point de coupure qui arrête la machine cible lorsque les commandes de point de coupure sont envoyées de l'hôte à la cible est d'utilité limitée, car la cible sera incapable de satisfaire en temps réel les demandes de son application.
2.2 Relation aux autres protocoles
LDP est un protocole d'application qui se fond dans l'environnement en couches du protocole Internet. La Figure 1 illustre la place de LDP dans la hiérarchie des protocoles.
Figure 1 : Relation avec les autres protocoles
LDP exige que la couche de transport sous-jacente :
o permette d'ouvrir les connexions en spécifiant une adresse réseau (ou internet). Accepte l'ouverture passive et active.
o pour chaque connexion, spécifie la taille de message maximum.
o fournisse un mécanisme d'envoi et de réception des messages sur une connexion ouverte.
o livre les messages de façon fiable et en séquence.
o accepte les connexions multiples, et distingue les messages associés aux différentes connexions. Cette exigence est seulement pour le cas où LDP prend en charge plusieurs usagers en même temps.
o retourne explicitement le résultat (réussite/échec) de chaque demande (ouverte, envoyée, demande), et fournisse un moyen d'interroger l'état d'une connexion (compte de message non acquitté, etc.).
Les données sont passées du programme d'application au processus d'utilisateur LDP sous la forme de commandes. Dans le cas d'un processus de serveur LDP, les réponses aux commandes sont générées dans LDP lui-même. En dessous de LDP se trouve le protocole de transport. Le protocole de données fiables (RDP, Reliable Data Protocol -- RFC 908) est le protocole de transport recommandé. Les données sont passées à travers l'interface LDP/RDP sous forme de messages. (TCP peut être utilisé à la place de RDP, mais il sera moins efficace et exigera plus de ressources de mise en œuvre.) Une couche internet (IP) vient normalement entre RDP et la couche réseau, mais RDP peut échanger des paquets de données directement avec la couche réseau.
La Figure 2 montre le flux des données à travers les interfaces du protocole :
Figure 2 : Forme de l'échange des données entre les couches
3. Fonctionnement du protocole
Une session LDP consiste en un échange de commandes et de réponses entre un processus d'utilisateur LDP et un processus de serveur LDP. Normalement, le processus d'utilisateur réside sur une machine hôte (un ordinateur en temps partagé utilisé pour la surveillance et le contrôle du réseau), et le processus serveur réside sur une machine cible (PSN, PAD, routeur, etc.). Tout au long de ce document, hôte et cible sont utilisés respectivement comme synonymes de processus d'utilisateur et de processus de serveur, bien que dans certaines mises en œuvre (le Butterfly, par exemple) cette correspondance puisse être inversée. L'hôte contrôle la session en envoyant des commandes à la cible. Certaines commandes peuvent provoquer des réponses, et toutes les commandes peuvent provoquer une réponse d'erreur.
Le protocole contient cinq classes de commandes : protocole, transfert de données, gestion, contrôle et point de coupure. Les commandes de protocole sont utilisées pour vérifier le mécanisme de séquençage des commandes et pour traiter les commandes erronées. Les commandes de transfert de données impliquent le transfert de données d'un endroit à un autre, comme un examen/dépôt de mémoire, ou un chargement. Les commandes de gestion sont utilisées pour créer et supprimer des objets (processus, points de coupure, points d'observation, etc.) dans la machine cible. Les commandes de contrôle sont utilisées pour contrôler l'exécution des codes et points de coupure cible. Les commandes de point de coupure sont utilisées pour contrôler l'exécution des commandes à l'intérieur des points de coupure et des points d'observation.
Une session LDP consiste en une série de commandes envoyées d'un hôte LDP à une cible LDP, dont certaines peuvent être suivies de réponses de la part de la cible. Une session commence lorsque un hôte ouvre une connexion de transport avec une cible qui écoute sur un accès bien connu. LDP utilise le numéro d'accès RDP zzz ou le numéro d'accès TCP yyy. Lorsque la connexion a été établie, l'hôte envoie une commande HELLO, et la cible réplique par HELLO_REPLY. HELLO_REPLY contient des paramètres qui décrivent la mise en œuvre LDP de la cible, y compris la version du protocole; le niveau de mise en œuvre, le type de système, et le format d'adresse. La session se termine lorsque l'hôte clôt la connexion de transport sous-jacente. Lorsque la cible détecte que la connexion de transport a été close, elle devrait désaffecter toutes les ressources dédiées à la session.
Le processus de cible est le partenaire passif dans une session LDP, et il attend que l'achèvement du processus d'hôte termine la session. Au titre des considérations pour la mise en œuvre, LDP ou le protocole de transport sous-jacent dans la cible devrait avoir une méthode pour détecter si le processus de l'hôte est arrivé à expiration. Autrement, une cible LDP qui ne prend en charge qu'une seule connexion pourrait être rendue inutile par un hôte défaillant au milieu d'une session. Le problème de la détection des connexions à moitié mortes peut être évité par une approche différente : la cible peut permettre à de nouvelles connexions de supplanter les connexions inactives. Une connexion sans activité pourrait être déclarée 'morte', mais ne serait pas supplantée avant que la ressource de connexion ne soit nécessaire. Cependant, cela exigerait encore que la couche transport prenne en charge deux canaux de connexion : un pour recevoir les demandes de connexion, et un autre à utiliser pour une connexion active.
Chaque commande envoyée de l'hôte à la cible a un numéro de séquence. Le numéro de séquence est utilisé par la cible pour se référer à la commande dans les répliques normales et dans les réponses d'erreur. Pour économiser l'espace, ces numéros ne sont pas réellement inclus dans les commandes d'hôte. Au lieu de cela, chaque commande envoyée de l'hôte est affectée d'un numéro de séquence implicite. Le numéro de séquence commence à zéro au début de la session LDP et augmente de un à chaque commande envoyée. L'hôte et la cible gardent chacun trace du numéro en cours. La commande SYNCH <sequence number> peut être utilisée par l'hôte pour synchroniser le numéro de séquence.
3.4 Mise en paquet et transmission des données
La convention pour l'ordre de mise en paquet des données a été choisie pour sa simplicité : les données sont mises en paquet avec le bit de plus fort poids en premier, dans l'ordre croissant d'adresse cible, en octets de huit bits. Les octets des données mises en paquet sont transmis dans l'ordre de la séquence.
Les données sont toujours mises en paquet selon le format d'adresse de la machine cible. Par exemple, dans une session LDP entre un hôte à 20 bits et une cible à 16 bits, des mots de 16 bits (mis en paquets en octets) sont transmis dans les deux directions. Pour faciliter l'exposé, les cibles sont traitées ici comme si elles avaient des espaces d'adresse uniformes. En pratique, la taille des unités d'adresse peuvent varier au sein d'une cible – macromémoire à 16 bits, micromémoire à 32 bits, mémoire de répartition à 10 bits, etc. La mise en paquet de données entre hôte et cible est faite sur mesure dans les unités actuelles de l'espace adresse cible.
Les figures qui montrent la mise en paquet des données pour les cibles qui ont diverses tailles d'unités d'adresse sont données ci-dessous. L'ordre de transmission par rapport aux diagrammes est de haut en bas. La numérotation des bits dans les diagrammes suivants se réfère au poids des bits dans l'octet : le bit zéro est le bit de moindre poids dans un octet. Pour une explication de la convention de numérotation des bits qui s'applique dans le reste de ce document, prière de se reporter à l'Appendice A.
La mise en paquet des données pour les cibles avec des longueurs de mots qui sont des multiples de 8 est directe. Le diagramme suivant illustre la mise en paquet à 16 bits:
7 0
---------------------------------
Octet 0 | MOT 0 bits 15-08 |
---------------------------------
Octet 1 | MOT 0 bits 07-00 |
---------------------------------
Octet 2 | MOT 1 bits 15-08 |
---------------------------------
Octet 3 | MOT 1 bits 07-00 |
---------------------------------
*
*
*
---------------------------------
Octet 2n-1 | MOT n bits 07-00 |
---------------------------------
Figure 3 : Mise en paquet de mots de 16 bits
La mise en paquet pour les cibles qui ont des longueurs de mots particulières est plus compliquée. Pour les machines à 20 bits, deux mot de données sont mis en paquet dans 5 octets. Lorsque un nombre impair de mots de 20 bits est transmis, l'octet partiellement utilisé est inclus dans la longueur de la commande, et l'octet est bourré de zéros à droite.
7 0
---------------------------------
Octet 0 | MOT 0 bits 19-12 |
---------------------------------
Octet 1 | MOT 0 bits 11-04 |
---------------------------------
Octet 2 |MOT 0 03-00|MOT 1 19-16 |
---------------------------------
Octet 3 | MOT 1 bits 15-08 |
---------------------------------
Octet 4 | MOT 1 bits 07-00 |
---------------------------------
Figure 4 : Mise en paquet de mots de 20 bits
Un sous-ensemble des commandes LDP peut être mis en œuvre dans les cibles lorsque les ressources machine sont limitées et que les pleines capacités de LDP ne sont pas nécessaires. Il y a trois niveaux de base de mise en œuvre de cible : LOADER_DUMPER, BASIC_DEBUGGER et FULL_DEBUGGER. La cible communique son niveau de mise en œuvre LDP à l'hôte durant l'initialisation de session. Les niveaux de mise en œuvre sont décrits ci-dessous.
LOADER_DUMPER
Utilisé pour le chargement/dépôt de la machine cible. Inclut toutes les commandes et répliques de classe de protocole ; les commandes de transfert des données READ, WRITE, MOVE et leurs réponses ; la commande de contrôle START et la réplique de contrôle EXCEPTION. A au moins la compréhension des modes d'adressage PHYS_MACRO et HOST ; et d'autres si désiré.
BASIC_DEBUGGER
Met en œuvre les commandes LOADER_DUMPER, toutes les commandes de contrôle, tous les modes d'adressage appropriés à la machine cible, mais n'a pas de points de coupure ou de points d'observation d'automate à états finis (FSM, finite state machine). Des points de coupure par défaut sont mis en œuvre. La cible comprend le mode d'adressage long.
FULL_DEBUGGER
Met en œuvre toutes les commandes et les modes d'adressage appropriés à la machine cible, et inclut des commandes de point de coupure, des commandes conditionnelles et POINT DE COUPURE_DATA. Les points d'observation sont facultatifs.
Les commandes LDP sont encloses dans les messages de transport RDP. Un message RDP peut contenir plus d'une commande, mais chaque commande doit tenir entièrement au sein d'un seul message. Les paquets réseau qui contiennent les commandes LDP ont le format indiqué à la Figure 5.
+----------------+
| En-tête de |
| réseau local |
+----------------+
| En-tête IP |
+----------------+
| En-tête RDP |
+----------------+ +-+
| En-tête de | |
| commande LDP | |
+----------------+ |
| Données | |
. LDP . | Format de
. facultatives . | commande LDP
| | |
+----------------+ |
| Bourrage LDP | |
+----------------+ +-+
| Commandes |
. LDP .
. supplémentaires.
. .
+----------------+
Figure 5 : Format de paquet réseau
Les commandes LDP comportent un en-tête standard de deux mots suivi facultativement par des données supplémentaires. Pour faciliter l'analyse des messages multi-commandes, toutes les commandes contiennent un nombre pair d'octets. Les commandes qui contiennent un nombre impair d'octets de données doivent être bourrées avec un octet nul.
Les commandes définies par la spécification LDP sont destinées à être d'application universelle pour fournir une base commune pour toutes les mises en œuvre. Les codes de classe et de type de commande de 0 à 63 sont réservés par le protocole. Les codes au dessus de 63 sont disponibles pour la mise en œuvre de commandes spécifiques de la cible.
Les commandes LDP commencent par un en-tête de longueur fixe. L'en-tête spécifie le type de commande et sa longueur en octets.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande (octets) |
+---------------+---------------+
1 | Classe de cmd | Type de cmd |
+---------------+---------------+
Figure 6 : Format d'en-tête de commande LDP
Champs d'en-tête :
Longueur de commande
La longueur de commande donne le nombre total d'octets dans la commande, y compris le champ de longueur et les données, et en excluant le bourrage.
Classe de commande
Type de commande
La classe et le type de commande spécifient ensemble une commande particulière. La classe sélectionne une des six catégories de commande, et le type donne la commande au sein de cette catégorie. Tous les codes sont en décimal. Les symboles donnés dans les Figures 7 et 8 pour les classes et types de commande sont utilisés comme référence dans le reste du présent document.
Les classes de commande qui ont été définies sont :
Classe de commande |
Symbole |
1 |
PROTOCOL |
2 |
DATA_TRANSFER |
3 |
CONTROL |
4 |
MANAGEMENT |
5 |
BREAKPOINT |
6 |
CONDITION |
7 – 63 |
<réservé> |
Figure 7 : Classes de commandes
Les codes de type de commande sont alloués dans l'ordre de leur fréquence prévue d'utilisation. Les commandes et leurs réponses/répliques sont numérotées en séquence. Les types de commande, ordonnés par classe de commande, sont :
Classe de commande |
Type de commande |
Symbole |
PROTOCOL |
1 |
HELLO |
2 |
HELLO_REPLY |
|
3 |
SYNCH |
|
4 |
SYNCH_REPLY |
|
5 |
ERROR |
|
6 |
ERRACK |
|
7 |
ABORT |
|
8 |
ABORT_DONE |
|
9 – 63 |
<réservé> |
|
DATA_TRANSFER |
1 |
WRITE |
2 |
READ |
|
3 |
READ_DONE |
|
4 |
READ_DATA |
|
5 |
MOVE |
|
6 |
MOVE_DONE |
|
7 |
MOVE_DATA |
|
8 |
REPEAT_DATA |
|
9 |
BREAKPOINT_DATA |
|
10 |
WRITE_MASK |
|
11 – 63 |
<réservé> |
|
CONTROL |
1 |
START |
2 |
STOP |
|
3 |
CONTINUE |
|
4 |
STEP |
|
5 |
REPORT |
|
6 |
STATUS |
|
7 |
EXCEPTION |
|
8 – 63 |
<réservé> |
|
MANAGEMENT |
1 |
CREATE |
2 |
CREATE_DONE |
|
3 |
DELETE |
|
4 |
DELETE_DONE |
|
5 |
LIST_ADDRESSES |
|
6 |
ADDRESS_LIST |
|
7 |
GET_PHYS_ADDRESS |
|
8 |
GOT_PHYS_ADDRESS |
|
9 |
GET_OBJECT |
|
10 |
GOT_OBJECT |
|
11 |
LIST_BREAKPOINTS |
|
12 |
BREAKPOINT_LIST |
|
13 |
LIST_NAMES |
|
14 |
NAME_LIST |
|
15 |
LIST_PROCESSES |
|
16 |
PROCESS_LIST |
|
17 – 63 |
<réservé> |
|
POINT DE COUPURE |
1 |
INCREMENT |
2 |
INC_COUNT |
|
3 |
OR |
|
4 |
SET_PTR |
|
5 |
SET_STATE |
|
6 – 63 |
<réservé> |
|
CONDITION |
1 |
CHANGED |
2 |
COMPARE |
|
3 |
COUNT_EQ |
|
4 |
COUNT_GT |
|
5 |
COUNT_LT |
|
6 |
TEST |
|
7 – 63 |
<réservé> |
|
Les adresses sont utilisées dans les commandes LDP pour se référer aux localisations de mémoire, aux processus, aux mémoires tampons, aux points de coupure et aux autres entités. Beaucoup de ces entités dépendent de la machine ; certaines machines ont des objets nommés, certaines machines ont plusieurs espaces d'adresse, la taille des espaces d'adresse varie, etc. Le format pour spécifier les adresses a besoin d'être assez général pour couvrir tous ces cas. Cela parle en faveur d'un format d'adresse grand, structuré hiérarchiquement. Cependant, l'inconvénient d'un grand format est qu'il impose une redondance supplémentaire aux communications avec les cibles qui ont de plus simples schémas d'adresse.
LDP résout ce conflit en employant deux formats d'adresse : un format court de trois mots pour s'adresser aux cibles plus simples, et un format long de cinq mots pour les autres. Il est requis de chaque cible LDP qu'elle mette en œuvre au moins un de ces formats. Au début d'une session LDP, la cible spécifie le ou les formats d'adresse qu'elle utilise dans le champ Fanion du message HELLO_REPLY. Dans chaque adresse, le premier bit de l'octet de mode est un fanion de format : 0 indique le format d'adresse LONG, et 1 indique le format COURT.
Le format d'adresse long fait cinq mots et consiste en un descripteur d'adresse de trois mots et un décalage de deux mots (voir la Figure 9). Le descripteur spécifie un espace d'adresse auquel le décalage est appliqué. Le descripteur est subdivisé en plusieurs champs, comme décrit ci-dessous. La structuration du descripteur est conçue pour prendre en charge des modes d'adressage complexes. Par exemple, sur les cibles qui ont des processeurs multiples, les descripteurs peuvent faire référence à des adresses virtuelles, des registres, et autres entités au sein d'un procès particulier.
Les modes d'adressage définis ci-dessous sont destinés à être la base sur laquelle des modes spécifiques de la cible peuvent être ajoutés. Les modes jusqu'à 63 sont réservés par le protocole. La gamme 64 à 127 peut être utilisée pour des modes d'adresse spécifiques de cible.
Le bit de format du format long est LONG=0
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+ +-+
|0| Mode | Argumt de mode | |
+-------------------------------+ |
| (31-16) | | Descripteur
+---- ID ---+ |
| (15-0) | |
+-------------------------------+ +-+
| (31-16) | |
+---- Décalage ---+ | Décalage
| (15-0) | |
+-------------------------------+ +-+
Figure 9 : Format d'adresse long
Champs de l'adresse longue :
Mode
Le mode de l'adresse identifie le type de l'espace d'adresse référencé. Le mode est qualifié par l'argument de mode et le champ ID. La mise en œuvre de modes autres que physique et hôte dépend de la machine. Actuellement, les modes définis et l'espace d'adresse qu'ils référencent sont indiqués à la Figure 10.
Mode |
Symbole |
Espace d'adresse |
0 |
HOST |
Hôte |
1 |
PHYS_MACRO |
Macromémoire |
2 |
PHYS_MICRO |
Micromémoire |
3 |
PHYS_I/O |
Espace entrée/sortie |
4 |
PHYS_MACRO_PTR |
Macro contenant un pointeur |
5 |
PHYS_REG |
Registre |
6 |
PHYS_REG_OFFSET |
Registre plus décalage |
7 |
PHYS_REG_INDIRECT |
Registre contenant l'adresse d'un pointeur |
8 |
PROCESS_CODE |
Espace de code de processus |
9 |
PROCESS_DATA |
Espace de données de processus |
1 |
PROCESS_DATA_PTR |
Les données de processus contiennent un pointeur |
11 |
PROCESS_REG |
Registre virtuel de processus |
12 |
PROCESS_REG_OFFSET |
Registre de processus plus décalage |
13 |
PROCESS_REG_INDIRECT |
Registre de processus contenant l'adresse d'un pointeur |
14 |
OBJECT_OFFSET |
Objet de mémoire (file d'attente, réserve commune) |
15 |
OBJECT_HEADER |
En-tête système pour un objet |
16 |
BREAKPOINT |
Point de coupure |
17 |
WATCHPOINT |
Point d'observation |
18 |
BPT_PTR_OFFSET |
Pointeur de point de coupure plus décalage |
19 |
BPT_PTR_INDIRECT |
Pointeur de point de coupure plus décalage donne l'adresse d'un pointeur |
20 – 63 |
<réservé> |
|
Figure 10 : Modes d'adresse longue
Argument de mode
Fournit un argument numérique pour le champ mode. Il spécifie le registre en modes physique et processus REG et REG_DÉCALAGE.
Champ d'ID
Identifie un processus, mémoire tampon ou objet, particulier.
Décalage
C'est le décalage dans l'espace d'adresse linéaire défini par le mode. La taille du mot machine détermine le nombre de bits significatifs dans le décalage. De même, les unités d'adressage de la cible sont les unités du décalage.
L'interprétation de l'argument de mode, du champ d'ID et du décalage pour chaque mode d'adresse est donné ci-dessous :
HOST
Les champs ID et décalage sont des numéros alloués de façon arbitraire par le côté hôte du débogueur. Ces numéros sont utilisés dans les messages MOVE et MOVE_DATA. Les réponses MOVE_DATA qui contiennent ce mode comme destination sont envoyées par la cible à l'hôte. Cela peut survenir dans le débogage lorsque les données sont envoyées à l'hôte à partir du point de coupure de la cible.
PHYS_MACRO
Le décalage contient l'adresse physique de 32 bits d'une localisation en macromémoire. L'argument de mode et le champ ID ne sont pas utilisés. Par exemple, mode=PHYS_MACRO et décalage=1000 spécifient la localisation 1000 dans la mémoire physique.
PHYS_MICRO
Comme PHYS_MACRO, mais la localisation est dans la micromémoire.
PHYS_I/O
Comme PHYS_MACRO, mais la localisation est dans l'espace d'entrée/sortie.
PHYS_MACRO_PTR
Le décalage contient l'adresse d'un pointeur dans la macromémoire. La localisation pointée (l'adresse effective) est aussi dans la macromémoire. L'argument de mode et le champ d'ID ne sont pas utilisés.
PHYS_REG
L'argument de mode donne le registre physique. Si le registre est utilisé par le processus cible de LDP, la copie sauvegardée du contexte précédent est alors utilisée. Ce commentaire s'applique aussi au mode PHYS_REG_OFFSET. Le champ d'ID n'est pas utilisé.
PHYS_REG_OFFSET
Le décalage est ajouté au contenu d'un registre donné comme argument de mode. Le résultat est utilisé comme adresse physique dans la macromémoire. L'identifiant n'est pas utilisé.
PHYS_REG_INDIRECT
Le registre spécifié dans l'argument de mode contient l'adresse d'un pointeur dans la macromémoire. L'adresse effective est la localisation de macromémoire spécifiée dans le pointeur, plus le décalage. Le champ d'ID n'est pas utilisé.
PROCESS_CODE
L'ID est un identifiant de processus, le décalage est dans l'espace de code pour ce processus. L'argument de mode n'est pas utilisé.
PROCESS_DATA
L'ID est un identifiant de processus, le décalage est dans l'espace de données pour ce processus. L'argument de mode n'est pas utilisé. Sur les systèmes qui ne font pas la distinction entre espace de code et de données, ces deux modes sont équivalents, et font référence à l'espace d'adresse virtuelle du processus.
PROCESS_DATA_PTR
Le décalage contient l'adresse d'un pointeur dans l'espace de données du processus spécifié par l'identifiant. La localisation pointée (l'adresse effective) est aussi dans l'espace des données. L'argument de mode n'est pas utilisé.
PROCESS_REG
Donne accès aux registres (et autres données système) du processus donné par le champ ID. L'argument de mode 0 débute les registres. Après les registres, l'argument de mode est un décalage dans la zone système pour le processus.
PROCESS_REG_OFFSET
Le décalage plus le contenu du registre donné dans l'argument de mode spécifie une localisation dans l'espace de données du processus spécifié par l'identifiant.
PROCESS_REG_INDIRECT
Le registre spécifié dans l'argument de mode contient l'adresse d'un pointeur dans l'espace de données du processus donné par l'identifiant. L'adresse effective est la localisation dans l'espace de données du processus spécifié dans le pointeur, plus le décalage.
OBJECT_OFFSET (facultatif)
Le décalage est dans l'espace mémoire défini par l'identifiant d'objet dans ID. Recommandé pour le contrôle à distance des segments de paramètres.
OBJECT_HEADER (facultatif)
Le décalage est dans l'en-tête système pour l'objet spécifié par l'identifiant. Destiné à être utilisé avec le Butterfly.
BREAKPOINT
Le descripteur spécifie un point de coupure. Le décalage n'est jamais utilisé, ce type n'est utilisé que dans les descripteurs qui se réfèrent aux points de coupure. (Voir Points de coupure et Points d'observation, ci-dessous, pour une explication des descripteurs de point de coupure.)
WATCHPOINT
Le descripteur spécifie un point d'observation. Le décalage n'est jamais utilisé, ce type n'est utilisé que dans les descripteurs qui se réfèrent aux points d'observation. (Voir Points de coupure et Points d'observation, ci-dessous, pour une explication des descripteurs de point d'observation).
BPT_PTR_OFFSET
Pour ce mode et BPT_PTR_INDIRECT, l'argument de mode spécifie une des deux variables de pointeur de point de coupure local au point de coupure dans lequel cette adresse survient. Ces pointeurs et la commande SET_PTR qui les manipule fournissent une quantité arbitraire d'indication d'adresse. Ils sont destinés à être utilisés dans les structures de traversée des données : par exemple, à la poursuite de files d'attente. Dans BPT_PTR_OFFSET, le décalage est ajouté à la variable de pointeur pour donner l'adresse effective. Dans les cibles qui prennent en charge plusieurs processus, la localisation est dans l'espace de données du processus donné par l'identifiant. Autrement, la localisation est une adresse physique dans une macromémoire. Les modes BPT_PTR.* ne sont valides que dans les points de coupure et les points d'observation.
BPT_PTR_INDIRECT
Comme BPT_PTR_OFFSET, excepté qu'il utilise un niveau d'indication de plus. La variable de pointeur donnée par l'argument de mode plus le décalage spécifient une adresse qui pointe sur l'adresse effective. Voir la description de BPT_PTR_OFFSET pour une discussion de l'usage, des limitations et de l'espace d'adresse.
Le format d'adresse court est destiné à être utilisé dans des mises en œuvre où la redondance de protocole doit être minimisée. Ce format est un sous-ensemble du format d'adresse long : il contient les mêmes champs excepté le champ ID. Donc, le format d'adressage court ne prend en charge que les modes d'adresse HOST et PHYS_*. Seules les commandes de niveau de mise en œuvre LOADER_DUMPER peuvent être utilisées avec le format d'adressage court. Le format d'adresse court est long de trois mots, consistant en un mot de 16 bits qui décrit l'espace d'adresse, et un décalage de 32 bits.
Le bit format du format court est SHORT=1
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+
|1| Mode | Argt de mode |
+-------------------------------+ +-+
| (31-16) | |
+---- Décalage ---+ | Décalage
| (15-0) | |
+-------------------------------+ +-+
Figure 11 : Format d'adresse court
Champs d'adresse courts :
Mode
Le bit de poids fort est à 1, ce qui indique le format d'adresse court. Une liste des modes d'adresse pris en charge est donnée ci-dessous. L'interprétation des champs restants est celle décrite ci-dessus pour le format d'adressage long.
Mode |
Symbole |
Espace d'adresse |
0 |
HOST |
Hôte |
1 |
PHYS_MACRO |
Macromémoire |
2 |
PHYS_MICRO |
Micromémoire |
3 |
PHYS_I/O |
Espace d'entrée/sortie |
4 |
PHYS_MACRO_PTR |
Macro contenant un pointeur |
5 |
PHYS_REG |
Registre |
6 |
PHYS_REG_OFFSET |
Registre plus décalage |
7 |
PHYS_REG_INDIRECT |
Registre contenant l'adresse d'un pointeur |
8 – 32 |
<réservé> |
|
Figure 12 : Modes d'adresse courts
Les commandes du protocole sont utilisées pour le traitement des erreurs, pour la synchronisation du numéro de séquence de la commande, et pour communiquer les paramètres de mise en œuvre du protocole. Chaque commande du protocole a une réplique correspondante. Toutes les commandes du protocole sont envoyées de l'hôte à la cible, et les répliques vont dans la direction opposée.
La commande HELLO est envoyée par l'hôte pour signaler le début d'une session LDP. La cible répond par HELLO_REPLY.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | PROTOCOLE | HELLO |
+---------------+---------------+
Figure 13 : Format de la commande HELLO
Un HELLO_REPLY est envoyé par la cible en réponse à la commande HELLO au début d'une session LDP. Cette réplique est utilisée pour informer l'hôte de la mise en œuvre LDP par la cible.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | PROTOCOLE | HELLO_REPLY |
+---------------+---------------+
2 | Version LDP |Type de système|
+---------------+---------------+
3 | Options |W|S| Mise en œuvre |
+---------------+---------------+
4 | Code d'adresse| Réservé |
+---------------+---------------+
Figure 14 : Format de HELLO_REPLY
Champs de HELLO_REPLY :
Version LDP
C'est la version du protocole LDP de la cible. Si la version actuelle du protocole de l'hôte n'est pas en accord avec la version de protocole de la cible, l'hôte peut terminer la session ou peut la continuer, à la discrétion de l'exécutant. Le numéro de version actuel est 2.
Type de système
C'est le type de système qui fonctionne sur la cible. Ceci est utilisé comme vérification de ce que l'hôte pense qu'est la cible. L'hôte est supposé avoir un tableau des types de systèmes cible avec des informations sur les espaces adresse des cibles, les commandes spécifiques des cibles et les modes d'adressage, et ainsi de suite.
Les types de systèmes actuellement définis sont indiqués à la Figure 15. Cette liste inclut des systèmes normalement considérés comme des "hôtes" (par exemple, C70, VAX) pour des mises en œuvre dans lesquelles les cibles initient et dirigent activement une charge d'elles-mêmes.
Code |
Système |
Description |
1 |
C30_16_BIT |
BBN 16-bit C30 |
2 |
C30_20_BIT |
BBN 20-bit C30 |
3 |
H316 |
Honeywell-316 |
4 |
BUTTERFLY |
BBN Butterfly |
5 |
PDP-11 |
DEC PDP-11 |
6 |
C10 |
BBN C10 |
7 |
C50 |
BBN C50 |
8 |
PLURIBUS |
BBN Pluribus |
9 |
C70 |
BBN C70 |
10 |
VAX |
DEC VAX |
11 |
MACINTOSH |
Apple MacIntosh |
Code d'adresse
Le code d'adresse indique quel ou quels formats d'adresse LDP la cible est prête à utiliser. Les codes d'adresse sont donnés à la Figure 16.
Code d'adresse |
Symbole |
Description |
1 |
LONG_ADDRESS |
Format d'adresse de cinq mots. Accepte tous les modes d'adresse et de commandes. |
2 |
SHORT_ADDRESS |
Format d'adresse de trois mots. N'accepte que les modes d'adresse physique et d'hôte. Seul l'ensemble de commandes LOADER_DUMPER est pris en charge. |
Figure 16 : Codes d'adresse cible
Mise en œuvre
Le niveau de mise en œuvre spécifie les caractéristiques du protocole qui sont mises en œuvre dans la cible. Il y a trois niveaux de mise en œuvre de protocole. Ces niveaux sont destinés à correspondre aux trois applications les plus vraisemblables de LDP : simple chargement et déchargement, débogage de base, et débogage complet. (Prière de se reporter ci-dessus au paragraphe 3.5 "Mises en œuvre" pour une description détaillée des niveaux de mise en œuvre.) Il y a aussi plusieurs caractéristiques facultatives qui ne sont pas incluse dans un niveau particulier.
Les niveaux de mise en œuvre sont cumulatifs, c'est-à-dire que chaque niveau supérieur inclut les caractéristiques de tous les niveaux précédents. Les niveaux sont indiqués à la Figure 17.
Niveau de caractéristique |
Symbole |
Description |
1 |
LOADER_DUMPER |
Charge/décharge un sous-ensemble de LDP |
2 |
BASIC_DEBUGGER |
Commandes de contrôle, CREATE |
3 |
FULL_DEBUGGER |
Points de coupure FSM |
Figure 17 : Niveaux de caractéristiques
Options
Le champ options (voir la Figure 18) est un champ de fanions de huit bits. Les fanions binaires sont utilisés pour indiquer si la cible a mis en œuvre une commande facultative particulière. Toutes les commandes facultatives ne sont pas référencées dans ce champ. Les commandes dont la mise en œuvre dépend de caractéristiques de la machine cible sont omises. L'application LDP est supposée "connaître" les caractéristiques de la cible qui ne sont pas intrinsèques du protocole. Des exemples de commandes propres à la cible sont des commandes qui se réfèrent à des objets nommés (CREATE, LIST_NAMES).
Gabarit |
Symbole |
Description |
1 |
STEP |
La commande STEP est mise en œuvre |
2 |
WATCHPOINTS |
Les points d'observation sont mis en œuvre |
La commande SYNCH est envoyée par l'hôte à la cible. La cible répond par SYNCH_REPLY. L'échange SYNCH-SYNCH_REPLY sert deux fonctions : il synchronise le numéro de séquence implicite d'hôte à cible et agit comme accusé de réception cumulatif de la réception et de l'exécution de toutes les commandes de l'hôte jusqu'au SYNCH.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | PROTOCOLE | SYNCH |
+---------------+---------------+
2 | Numéro de séquence |
+---------------+---------------+
Figure 19 : Format de la commande SYNCH
Champs de SYNCH :
Numéro de séquence
C'est le numéro de séquence de cette commande. Si ce n'est pas ce que la cible attend, elle va se recaler sur lui et répondre par une réplique ERREUR.
SYNCH_REPLY est envoyé par la cible en réponse à une commande SYNCH valide. Une commande SYNCH est valide si son numéro de séquence est en accord avec le numéro de séquence qu'attend la cible. Autrement, la cible va recaler son numéro de séquence dans la commande SYNCH et envoyer une réplique ERREUR.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | PROTOCOLE | SYNCH_REPLY |
+---------------+---------------+
2 | Numéro de séquence |
+---------------+---------------+
Figure 20 : Format de SYNCH_REPLY
Champs de SYNCH_REPLY :
Numéro de séquence
C'est le numéro de séquence de la commande SYNCH à laquelle cette SYNCH_REPLY est la réponse.
La commande ABORT est envoyée à partir de l'hôte pour interrompre toutes les opérations en cours à la cible. La cible répond par ABORT_DONE. Ceci est principalement destiné à arrêter de gros transferts de données à partir de la cible. Une application vraisemblable serait au cours d'une session de débogage lorsque l'utilisateur tape une touche d'échappement pour interrompre une grosse impression de données provenant de la cible. La commande ABORT n'a pas d'effet sur les points de coupure ou points d'observation qui seraient activés à la cible.
En pratique, la commande ABORT pourrait être difficile à mettre en œuvre sur certaines cibles. Sa capacité à interrompre l'exécution d'une commande sur la cible dépend de la capacité de la cible à prévoir les commandes entrantes et à recevoir un signal hors bande de la part de l'hôte. Cependant, l'effet d'un ABORT peut être obtenu simplement en fermant et rouvrant la connexion de transport.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | PROTOCOLE | ABORT |
+---------------+---------------+
Figure 21 : Format de la commande ABORT
La réplique ABORT_DONE est envoyée de la cible à l'hôte en réponse à une commande ABORT. Cela indique que la cible a terminé toutes les opérations qui étaient en cours lorsque la commande ABORT a été reçue. Le numéro de séquence de la commande ABORT est inclus dans la réplique.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | PROTOCOLE | ABORT_DONE |
+---------------+---------------+
2 | Numéro de séquence |
+---------------+---------------+
Figure 22 : Format de réplique ABORT_DONE
Champs de ABORT_DONE :
Numéro de séquence
Le numéro de séquence de la commande ABORT qui a provoqué cette réplique. Cela permet à l'hôte de distinguer les répliques de plusieurs commandes ABORT.
La réplique ERROR est envoyée par la cible en réponse à une mauvaise commande. La réplique ERROR donne le numéro de séquence de la commande fautive et un code de cause. La cible ignore les commandes ultérieures jusqu'à réception d'une commande ERRACK. La raison d'ignorer ces commandes est que le bon fonctionnement des commandes en instance peut contenir les prémices de l'exécution de la commande erronée.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | PROTOCOLE | ERROR |
+---------------+---------------+
2 | Numéro de séquence de commande|
+---------------+---------------+
3 | Code d'erreur |
+---------------+---------------+
4 | Données facultatives |
+---------------+---------------+
*
*
*
+---------------+---------------+
n | Données facultatives |
+---------------+---------------+
Figure 23 : Format de la réplique ERROR
Champs de la réplique ERROR :
Numéro de séquence de commande
C'est le numéro de séquence implicite de la commande erronée.
Code d'erreur
C'est un code qui spécifie quelle erreur est survenue. Les codes actuellement définis sont donnés à la Figure 24.
Code d'erreur |
Symbole |
1 |
BAD_COMMAND |
2 |
BAD_ADDRESS_MODE |
3 |
BAD_ADDRESS_ID |
4 |
BAD_ADDRESS_OFFSET |
5 |
BAD_CREATE_TYPE |
6 |
NO_RESOURCES |
7 |
NO_OBJECT |
8 |
OUT_OF_SYNCH |
9 |
IN_BREAKPOINT |
L'explication de chacun de ces codes d'erreur suit :
BAD_COMMAND
La commande n'a pas de signification pour la machine cible. Cela inclut les commandes qui sont valides mais non mises en œuvre par cette cible. Aussi, la commande n'était pas valide dans ce contexte. Par exemple, une commande donnée par l'hôte qui n'est légale que dans un point de coupure (par exemple, IF, SET_STATE).
BAD_ADDRESS_MODE <offending-address>
Le mode d'une adresse donnée dans la commande n'a pas de signification pour ce système cible. Par exemple, un mode d'adresse PROCESS sur une cible qui ne prend pas en charge le multi-traitement.
BAD_ADDRESS_ID <offending-address>
Le champ ID d'une adresse ne correspondait pas à une chose appropriée. Par exemple, pour un mode d'adresse PROCESS, l'identifiant d'un processus non existant.
BAD_ADDRESS_OFFSET <offending-address>
Le champ décalage de l'adresse était en dehors de la gamme légale pour la chose visée. Par exemple, un décalage de 200 000 en mode PHYS_MACRO sur une cible avec 64 K de macro-mémoire.
BAD_CREATE_TYPE
Le type d'objet dans une commande CREATE était inconnu.
NO_RESOURCES
Une commande CREATE a échoué à cause du manque des ressources nécessaires.
NO_OBJECT
Une commande GET_OBJECT a échoué à trouver l'objet nommé.
OUT_OF_SYNCH
Le numéro de séquence de la commande SYNCH n'était pas attendu par la cible. Le cible s'est resynchronisée sur lui.
IN_BREAKPOINT <breakpoint-descriptor> <breakpoint-sequence#> <reason-code> [<optional-info>]
Une erreur est survenue au sein d'une liste de commande de point de coupure. Le numéro de séquence de 16 bits donné se réfère au numéro de séquence de la commande CREATE qui a créé le point de coupure, alors que le numéro de séquence de point de coupure se réfère au numéro de séquence de la commande au sein du point de coupure donné par <breakpoint-descriptor>.
5.8 Accusé de réception ERRACK
Un ERRACK est envoyé par l'hôte en réponse à une réplique ERROR provenant de la cible. Le ERRACK est utilisé pour accuser réception de ce que l'hôte a reçu la réplique ERROR.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | PROTOCOLE | ERRACK |
+---------------+---------------+
Figure 25 : Format de commande ERRACK
6 Commandes de transfert de données
Les commandes de transfert de données transfèrent les données entre l'hôte et la cible. Ces commandes sont utilisées pour charger et décharger la cible, et examiner et mettre en dépôt des localisations sur la cible. La commande READ lit les données de la cible, la commande MOVE déplace les données au sein de la cible ou de la cible à une autre entité, et la commande WRITE écrit des données sur la cible. REPEAT_DATA fait des copies d'un schéma sur la cible – c'est utile pour mettre à zéro une mémoire. WRITE_MASK écrit des données avec un gabarit, et est destiné à modifier les tableaux de paramètres de la cible.
Les données transmises de et vers la cible contiennent toujours une adresse de cible. Dans les écritures sur la cible, ceci est utilisé comme destination des données. Dans les lectures sur la cible, l'adresse de la cible est utilisée par l'hôte pour identifier d'où viennent les données dans la cible. De plus, la commande MOVE peut contenir une adresse "d'hôte" comme destination ; cela permet à l'hôte de préciser la discrimination entre les sources de données possibles dans la cible – à partir de différents points de coupure, fenêtres de débogage, etc.
Une demande de lecture à la cible peut générer un ou plusieurs messages de réponse. En particulier, les réponses à des demandes pour de grosses quantités de données – dépôts de cœur de système, par exemple – doivent être fragmentées en plusieurs messages si le bloc des données demandées plus l'en-tête LDP excède la taille du message de couche transport.
Dans les commandes qui contiennent des données (WRITE, READ_DATA, MOVE_DATA et REPEAT_DATA), si il y a un nombre impair d'octets de données, un octet nul est alors ajouté. Ceci est fait de sorte que la prochaine commande dans le message, s'il en est, commence sur un octet pair. La longueur de commande est la somme du nombre des octets dans l'en-tête de commande et du nombre d'octets de données, en excluant l'octet nul, s'il en est.
Les formats d'adressage qui peuvent être utilisés avec les commandes de transfert de données sont spécifiés pour chaque session LDP au début de la session par la cible dans la réponse HELLO_REPLY. Voir au paragraphe 4.3 "Adressage" ci-dessus la description des formats et modes d'adressage de LDP. Dans les diagrammes de commandes donnés ci-dessous, le format d'adressage court est illustré. Pour les sessions LDP qui utilisent l'adressage long, les adresses sont de cinq mots au lieu de trois mots comme indiqué ici. Dans les deux modes d'adressage, les descripteurs sont de trois mots et les décalages sont de deux mots.
La commande WRITE est utilisée pour envoyer des octets de données de l'hôte à la cible. Cette commande spécifie l'adresse dans la cible où les données sont à mémoriser, suivie par un flux d'octets de données. Si le flux de données contient un nombre impair d'octets, un octet nul est alors ajouté de façon à ce que la prochaine commande, s'il en est, commence sur un octet pair. Comme LDP doit respecter les limitations de taille de message imposées par la couche de transport sous-jacente, une écriture logique unique peut devoir être coupée en plusieurs commandes WRITE dans des messages de transport séparés.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | DATA_TRANSFER | WRITE |
+---------------+---------------+
2 | |
+-- Adresse --+
3 | de début |
+-- de cible --+
4 | |
+---------------+---------------+
5 |Octet de donnée|Octet de donnée|
+---------------+---------------+
*
*
*
+---------------+---------------+
n |Octet de donnée|Données ou Nul |
+---------------+---------------+
Figure 26 : Format de la commande WRITE
Champs de WRITE :
Longueur de commande
La longueur de commande donne le nombre d'octets dans la commande, y compris les octets de données, mais en excluant l'octet de bourrage, s'il en est.
Adresse de début de cible
C'est l'adresse où commencer la mémorisation des données dans la cible. La longueur des données à mémoriser peut être déduite par la cible de la longueur de la commande. Une adresse ou gamme illégale va générer une réplique ERROR.
Octets de données
Les octets de données à mémoriser dans la cible. Les données sont mises en paquet conformément à la convention de mise en paquet décrite ci-dessus. Ils se terminent par un octet nul si il y a un nombre impair d'octets de données.
L'hôte utilise la commande READ pour demander à la cible de renvoyer un bloc contigu de données. Les données sont spécifiées par une adresse de début de cible et un compte. La cible retourne les données en une ou plusieurs commandes READ_DATA, qui donnent l'adresse de début (dans la cible) de chaque segment des données retournées. Lorsque le transfert est achevé, la cible envoie une commande READ_DONE à l'hôte.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 14 |
+---------------+---------------+
1 | DATA_TRANSFER | READ |
+---------------+---------------+
2 | |
+-- Adresse --+
3 | de début |
+-- de cible --+
4 | |
+---------------+---------------+
5 | Compte |
+-- d'unités --+
6 | d'adresse |
+---------------+---------------+
Figure 27 : Format de la commande READ
Champs de READ :
Adresse de début de cible
C'est l'adresse de début du bloc demandé des données de la cible. La cible envoie une réplique ERROR si l'adresse de début est illégale, si l'adresse de fin calculée d'après la somme du début et du compte est illégale, ou si des trous sont rencontrés dans le cours de la gamme.
Compte d'unités d'adresse
C'est le compte du nombre des unités indivisibles d'adressage de la cible à transférer. Par exemple, si l'espace d'adresse est PHYS_MACRO, un compte de deux et une adresse de début de 1000 sélectionnent le contenu des localisations 1000 et 1001. "Compte" est utilisé à la place de "longueur" pour éviter le problème d'avoir à déterminer les unités de longueur qui devraient être désignées (octets, mots, etc.). La taille et le type de l'unité vont varier selon l'espace d'adresse choisi par l'adresse de début de cible. La cible devrait répliquer par une erreur (si elle est capable de le déterminer avant un transfert) si la gamme inclusive des adresses spécifiées par l'adresse de début et le compte contient une adresse illégale ou non existante.
La cible utilise la réponse READ_DATA pour transmettre les données demandées par la commande READ d'un hôte. Une ou plusieurs réponses READ_DATA peuvent être nécessaires pour satisfaire une commande READ donnée, selon la taille du bloc de données demandé et les limites de taille de message de la couche transport. Chaque réponse READ_DATA donne l'adresse de début de la cible de son segment de données. Si la réponse contient un nombre impair d'octets de données, la cible termine la réponse par un octet nul.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | DATA_TRANSFER | READ_DATA |
+---------------+---------------+
2 | |
+-- Adresse --+
3 | de début |
+-- de cible --+
4 | |
+---------------+---------------+ +-+
5 |Octet de donnée|Octet de donnée| |
+---------------+---------------+ |
* |
* | Données
* |
+---------------+---------------+ |
n |Octet de donnée|Données ou Nul | |
+---------------+---------------+ +-+
Figure 28 : Format de réponse de DATA
Champs de READ_DATA :
Longueur de commande
La longueur de commande donne le nombre d'octets dans la commande, en incluant les octets de données, mais en excluant l'octet de bourrage, s'il en est. L'hôte peut calculer la longueur des données en soustrayant la longueur de l'en-tête de la longueur de la commande. Comme l'adresse de la cible peut être soit de trois mots (format court) soit de cinq mots (format long), le mode d'adresse doit être vérifié pour déterminer lequel est utilisé.
Adresse de début de cible
C'est l'adresse du début du segment de données dans ce message. L'hôte peut déduire la longueur des données de la longueur de la commande. Le format d'adresse (court ou long) est le même que dans la commande READ initiale.
Octets de données
Ce sont les octets de données provenant de la cible. Les données sont mises en paquet conformément à la convention de mise en paquet décrite ci-dessus. Ils se terminent par un octet nul si il y a un nombre impair d'octets de données.
La cible envoie une réplique READ_DONE à l'hôte après qu'elle a fini de transférer les données demandées par une commande READ. READ_DONE spécifie le numéro de séquence de la commande READ.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | DATA_TRANSFER | READ_DONE |
+---------------+---------------+
2 | Numéro de séquence de READ |
+---------------+---------------+
Figure 29 : Format de la réplique READ_DONE
Champs de READ_DONE :
Numéro de séquence de READ
C'est le numéro de la séquence de la commande READ à laquelle s'adresse cette réplique.
La commande MOVE est envoyée par l'hôte pour déplacer un bloc de données de la cible vers une destination spécifiée. L'adresse de destination peut spécifier une localisation dans la cible, dans l'hôte, ou dans une autre cible (pour charger une cible à partir d'une autre). Les données sont spécifiées par une adresse de début de cible et un compte d'unités d'adresse. La cible envoie une réplique ERROR si l'adresse de début est illégale, si l'adresse de fin calculée à partir de la somme du début et du compte est illégale, ou si des trous sont trouvés dans la gamme. Si la destination de MOVE est hors cible, la cible déplace les données dans une ou plusieurs MOVE_DATA. Les autres commandes qui arrivent à la cible durant le transfert devraient être traitées en temps voulu, en particulier la commande ABORT. Lorsque les données ont été déplacées, la cible envoie un MOVE_DONE à l'hôte. Cependant, un MOVE au sein d'un point de coupure ne génèrera pas de MOVE_DONE.
Un MOVE avec une destination d'hôte diffère d'un READ en ce qu'il contient une adresse d'hôte. Ce champ est spécifié par l'hôte dans la commande MOVE et est copié par la cible dans le ou les MOVE_DATA correspondants. L'adresse peut être utilisée par l'hôte pour différencier les données retournées de plusieurs demandes MOVE. Ces informations peuvent être utiles dans les points de coupure, dans le débogage multifenêtre et dans les communications avec des cibles qui ont plusieurs processeurs. Par exemple, l'hôte envoie la commande MOVE à la cible pour qu'elle soit exécutée durant un point de coupure. Le champ ID dans l'adresse d'hôte pourrait être un index dans le tableau de point de coupure de l'hôte.
Lorsque le point de coupure s'exécute, l'hôte va utiliser l'identifiant pour associer le MOVE_DATA retourné avec ce point de coupure.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | DATA_TRANSFER | MOVE |
+---------------+---------------+
2 | |
+-- Adresse --+
3 | de début |
+-- de source --+
4 | |
+---------------+---------------+
5 | Compte |
+-- d'unités --+
6 | d'adresse |
+---------------+---------------+
7 | |
+-- Adresse --+
8 | de début de |
+-- destination --+
9 | |
+---------------+---------------+
Figure 30 : Format de la commande MOVE
Champs de MOVE :
Adresse de début de source
C'est l'adresse du début du bloc demandé de données de la cible. Un type d'adresse illégal va générer une réplique d'erreur.
Compte d'unités d'adresse
C'est le compte du nombre d'unités indivisibles d'adressage de la source à transférer. Par exemple, si l'espace d'adresse est PHYS_MACRO, un compte de deux et une adresse de début de 1000 sélectionne le contenu des localisations 1000 et 1001. "Compte" est utilisé à la place de "longueur" pour éviter le problème d'avoir à déterminer les unités dans lesquelles la longueur devrait être désignée (octets, mots, etc.). La taille et le type de l'unité vont varier selon l'espace d'adresse choisi par l'adresse de début de cible. La cible devrait répliquer par une erreur (si elle est capable de le déterminer avant le transfert) si la gamme inclusive des adresses spécifiées par l'adresse de début et le compte contiennent une adresse illégale ou non existante.
Adresse de destination
C'est la destination du MOVE. Si l'espace d'adresse est sur la cible, la taille d'unités d'adresse devrait être en accord avec celle de l'espace d'adresse de source. Si le mode d'adresse est HOST, les valeurs et interprétations des champs d'adresse restants sont arbitraires et sont déterminées par la mise en œuvre de l'hôte. Par exemple, l'argument de mode peut spécifier un tableau (point de coupure, fenêtre de débogage, etc.) et le champ ID un indice dans ce tableau.
La cible utilise les réponses MOVE_DATA pour transmettre les données demandées par la commande MOVE d'un hôte. Une ou plusieurs réponses MOVE_DATA peuvent être nécessaires pour satisfaire une commande MOVE donnée, selon la taille du bloc de données demandé et les limites de taille de message de la couche transport. Chaque réponse MOVE_DATA donne l'adresse de début de cible de son segment de données. Si la réponse contient un nombre impair d'octets de données, la cible devrait terminer la réponse par un octet nul.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | DATA_TRANSFER | MOVE_DATA |
+---------------+---------------+
2 | |
+-- Adresse --+
3 | de début |
+-- de source --+
4 | |
+---------------+---------------+
5 | |
+-- Adresse --+
6 | de début de |
+-- destination --+
7 | |
+---------------+---------------+ +-+
8 |Octet de donnée|Octet de donnée| |
+---------------+---------------+ |
* |
* | Données
* |
+---------------+---------------+ |
n |Octet de donnée|Données ou nul | |
+---------------+---------------+ +-+
Figure 31 : Format de réponse MOVE_DATA
Champs de MOVE_DATA :
Longueur de commande
La longueur de commande donne le nombre d'octets dans la commande, y compris les octets de données, mais sans l'octet de bourrage, s'il en est.
Adresse de début de source
C'est l'adresse du début du segment de données dans ce message. L'hôte peut déduire la longueur des données de la longueur de la commande.
Adresse de destination
C'est l'adresse de destination copiée de la commande MOVE qui a initié ce transfert. Dans le cas de HOST MOVE, ceci est utilisé par l'hôte pour identifier la source des données.
Octets de données
Ce sont les octets de données provenant de la cible. Les données sont mises en paquet conformément à la convention de mise en paquets décrite ci-dessus. Elle se termine par un octet nul si il y a un nombre impair d'octets de données.
La cible envoie une réplique MOVE_DONE à l'hôte après qu'elle a fini de transférer les données demandées par une commande MOVE. MOVE_DONE spécifie le numéro de séquence de la commande MOVE.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | DATA_TRANSFER | MOVE_DONE |
+---------------+---------------+
2 | Numéro de séquence de MOVE |
+---------------+---------------+
Figure 32 : Format de la réplique MOVE_DONE
Champs de MOVE_DONE :
Numéro de séquence de MOVE
C'est le numéro de séquence de la commande MOVE à laquelle c'est la réplique.
La commande REPEAT_DATA est envoyée par l'hôte pour écrire des copies d'un schéma spécifié dans la cible. Cela fournit une façon efficace de mettre à zéro la mémoire de la cible et d'initialiser les structures de données de la cible. La commande spécifie l'adresse de début de la cible, le nombre de copies du schéma à suivre, et un flux d'octets qui constitue le schéma.
Cette commande diffère des autres commandes de transfert des données en ce que l'effet d'une commande REPEAT_DATA avec un grand schéma est qu'elle ne peut pas être dupliquée par l'envoi des données en plus petits tronçons sur plusieurs commandes. Donc, la taille maximum d'un schéma qui peut être copié avec REPEAT_DATA va dépendre des limites de taille de message de la couche transport.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | DATA_TRANSFER | REPEAT_DATA |
+---------------+---------------+
2 | |
+-- Adresse --+
3 | de début |
+-- de la cible --+
4 | |
+---------------+---------------+
6 | Compte de répétitions |
+---------------+---------------+ +-+
7 |Octet de donnée|Octet de donnée| |
+---------------+---------------+ |
* |
* | Schéma
* |
+---------------+---------------+ |
n |Octet de donnée| Données ou nul| |
+---------------+---------------+ +-+
Figure 33 : Format de la commande REPEAT_DATA
Champs de REPEAT_DATA :
Longueur de commande
La longueur de la commande donne le nombre des octets dans la commande, y compris les octets de données dans le schéma, mais sans l'octet de bourrage, s'il en est.
Adresse de début de cible
C'est l'adresse du début de l'endroit où la première copie du schéma devrait être écrite dans la cible. Les copies successives du schéma sont faites de façon contiguë en commençant à cette adresse.
Compte de répétition
Le compte de répétition spécifie le nombre de copies du schéma qui devraient être faites dans la cible. Le compte de répétition devrait être supérieur à zéro.
Schéma
C'est le schéma à copier dans la cible, mis en paquets dans un flux d'octets. Les données sont mises en paquet conformément à la convention de mise en paquets décrite ci-dessus. Elle se termine par un octet nul si il y a un nombre impair d'octets de données.
6.9 Commande WRITE_MASK (facultative)
L'hôte envoie une commande WRITE_MASK à la cible pour écrire une ou plusieurs valeurs d'un gabarit. La commande utilise une adresse pour spécifier une localisation fondée sur la cible, suivie par un ou plusieurs triplets de valeur-gabarit-décalage. Chaque triplet donne un décalage par rapport à la base, une valeur, et un gabarit indiquant quels bits dans la localisation à ce décalage sont à changer.
Cette commande facultative est destinée à être utilisée à contrôler la cible en changeant les localisations dans un tableau. Par exemple, elle peut être utilisée pour changer les entrées dans un tableau de paramètre de la cible. L'opération de modification d'une localisation spécifiée avec une valeur d'un gabarit est destinée à être atomique. En d'autres termes, un autre processus de cible ne devrait pas être capable d'accéder à la localisation à modifier entre le début et la fin de la modification.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | DATA_TRANSFER | WRITE_MASK |
+---------------+---------------+
2 | |
+-- Adresse --+
3 | de base |
+-- cible --+
4 | |
+---------------+---------------+ +-+
5 | | |
+-- Décalage --+ |
6 | | |
+---------------+---------------+ | Triplets
7 | | | Décalage-gabarit
+-- Gabarit --+ | -valeur
8 | | |
+---------------+---------------+ |
9 | | |
+-- Valeur --+ |
10| | |
+---------------+---------------+ +-+
*
*
*
+---------------+---------------+ +-+
| | |
+-- Décalage --+ |
| | | Triplet
+---------------+---------------+ | décalage-gabarit
| | | -valeur
+-- Gabarit --+ |
| | |
+---------------+---------------+ |
| | |
+-- Valeur --+ |
| | |
+---------------+---------------+ +-+
Figure 34 : Format de WRITE_MASK
Champs de WRITE_MASK :
Longueur de commande
La longueur de commande donne le nombre d'octets dans la commande. Le nombre de paires décalage-valeur peut être calculé à partir de cela, car l'en-tête de commande est long de 10 ou 12 octets (format d'adresse long ou court), et chaque triplet décalage-gabarit-valeur est long de 12 octets.
Adresse de base cible
Spécifie la localisation de la cible à laquelle est ajouté le décalage pour donner la localisation à modifier.
Décalage
Un décalage à ajouter à la base pour choisir une localisation à modifier.
Gabarit
Spécifie quels bits dans la valeur sont à copier dans la localisation.
Valeur
C'est une valeur à mémoriser au décalage spécifié à partir de la base. Les bits établis dans le gabarit déterminent quels bits dans la valeur sont appliqués à la localisation. L'algorithme suivant va réaliser le résultat attendu : prendre le complément à un du gabarit et l'ajouter par l'opérateur ET à la localisation, en laissant le résultat dans la localisation. Puis ajouter le gabarit et la valeur, et combiner par opérateur OU le résultat dans la localisation.
Les commandes de contrôle sont utilisées pour contrôler l'exécution du code cible, des points de coupure et des points d'observation. Elles sont aussi utilisées pour lire et rapporter l'état de ces objets. Les objets à contrôler ou rapporter sont spécifiés avec un descripteur. Les modes valides de descripteur incluent PHYS_* (pour certaines commandes) PROCESS_CODE, BREAKPOINT et WATCHPOINT. Les commandes de contrôle qui changent l'état de la cible sont START, STOP, CONTINUE et STEP. REPORT demande un rapport d'état sur un objet cible. EXCEPTION est un rapport spontané sur un objet, utilisé pour faire rapport d'événements asynchrones tels que des traps du matériel. L'hôte peut vérifier l'action d'une commande START, STOP, STEP ou CONTINUE en la suivant avec une commande REPORT.
La commande START est envoyée par l'hôte pour commencer l'exécution d'un objet spécifié dans la cible. Pour les cibles qui prennent en charge plusieurs processus, une adresse PROCESS_CODE spécifie le processus à commencer. Autrement, un des modes PHYS_* peut spécifier une localisation dans la macro-mémoire où l'exécution doit se poursuivre. Appliqué à un point de coupure ou un point d'observation, START règle la valeur de la variable d'état de l'objet, et active le point de coupure. Le compteur de point de coupure et les variables de pointeur sont initialisées à zéro.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 14 |
+---------------+---------------+
1 | CONTROL | START |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | |
+-- Champ --+ |
4 | d'identifiant | | Adresse
+-------------------------------+ |
5 | | |
+-- Décalage --+ |
6 | | |
+-------------------------------+ +-+
Figure 35 : Format de la commande START
Champs de START :
Adresse
Le descripteur spécifie l'objet à commencer. Si le mode est PROCESS_CODE, l'identifiant spécifie le processus à commencer, et le décalage donne l'adresse virtuelle à laquelle commencer le processus. Si le mode est PHYS_*, l'exécution de la cible est continuée à l'adresse spécifiée.
Pour les modes BREAKPOINT et WATCHPOINT, le décalage spécifie la nouvelle valeur de la variable d'état du FSM. Ceci est pour les points de coupure et points d'observation de FSM.
La commande STOP est envoyée par l'hôte pour arrêter l'exécution d'un objet spécifié dans la cible. Un descripteur spécifie l'objet. Appliqué à un point de coupure ou point d'observation, STOP le désactive. Le point de coupure/point d'observation peut être réactivé en produisant pour lui une commande START ou CONTINUE.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | CONTROL | STOP |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descripteur
+-- Champ --+ |
4 | d'identifiant | |
+-------------------------------+ +-+
Figure 36 : Format de la commande STOP
Champs de STOP :
Descripteur
Le descripteur spécifie l'objet à arrêter ou désactiver. Si le mode est PROCESS_CODE, l'identifiant spécifie le processus à arrêter. Pour les modes de BREAKPOINT et WATCHPOINT, le point de coupure ou point d'observation spécifié est désactivé. Il peut être réactivé par une commande CONTINUE ou START.
La commande CONTINUE est envoyée par l'hôte pour reprendre l'exécution d'un objet spécifié dans la cible. Un descripteur spécifie l'objet. Appliqué à un point de coupure ou à un point d'observation, CONTINUE l'active.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | CONTROL | CONTINUE |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descripteur
+-- Champ --+ |
4 | d'identifiant | |
+-------------------------------+ +-+
Figure 37 : Format de la commande CONTINUE
Champs de CONTINUE :
Descripteur
Le descripteur spécifie l'objet à reprendre ou réactiver. Si le mode est PROCESS_CODE, l'identifiant spécifie le processus à reprendre. Pour les modes BREAKPOINT et WATCHPOINT, le point de coupure ou point d'observation spécifié est activé.
La commande STEP est envoyée par l'hôte à la cible. Elle demande l'exécution d'une instruction (ou opération appropriée) dans l'objet spécifié par le descripteur.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | CONTROL | STEP |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descripteur
+-- Champ --+ |
4 | d'identifiant | |
+-------------------------------+ +-+
Figure 38 : Format de la commande STEP
Champs de STEP :
Descripteur
Le descripteur spécifie l'objet à traiter. Si le mode est PROCESS_CODE, l'identifiant spécifie un processus.
La commande REPORT est envoyée par l'hôte pour demander un rapport d'état sur un objet cible spécifié. L'état est retourné dans une réplique STATUS.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | CONTROL | REPORT |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descripteur
+-- Champ --+ |
4 | d'identifiant | |
+-------------------------------+ +-+
Figure 39 : Format de la commande REPORT
Champs de REPORT :
Descripteur
Le descripteur spécifie l'objet pour lequel un rapport STATUS est demandé. Pour un mode PROCESS_CODE, l'identifiant spécifie un processus. Les autres modes valides sont PHYS_MACRO, pour interroger l'état de l'application cible, et BREAKPOINT et WATCHPOINT, pour obtenir l'état d'un point de coupure ou point d'observation.
La cible envoie une réplique STATUS en réponse à une commande REPORT de l'hôte. STATUS donne l'état d'un objet spécifié. Par exemple, il peut dire si un processus de cible particulier fonctionne ou est arrêté.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | CONTROL | STATUS |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descripteur
+-- Champ --+ |
4 | d'identifiant | |
+-------------------------------+ +-+
5 | État |
+-------------------------------+ +-+
* |
* |
* | Autres données
+-------------------------------+ |
n | Autres données | |
+-------------------------------+ +-+
Figure 40 : Format de réplique STATUS
Champs de STATUS :
Descripteur
Le descripteur spécifie l'objet dont l'état est donné. Si le mode est PROCESS_CODE, l'identifiant spécifie alors un processus. Si le mode est PHYS_MACRO, l'état est alors celui de l'application cible.
État
Le code d'état décrit l'état de l'objet. Les codes d'état sont 0=STOPPED et 1=RUNNING. Pour les points de coupure et les points d'observation, STOPPED signifie désactivé et RUNNING signifie activé.
Autres données
Pour les points de coupure et les points d'observation, Autres données consiste en un mot de 16 bits qui donne la valeur actuelle de la variable d'état FSM.
Une EXCEPTION est un message spontané envoyé de la cible qui indique une exception de la machine cible associée à un objet particulier. L'objet est spécifié par une adresse.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | CONTROL | EXCEPTION |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | |
+-- Champ --+ |
4 | d'identifiant | | Adresse
+-------------------------------+ |
5 | | |
+-- Décalage --+ |
6 | | |
+-------------------------------+ +-+
7 | Type |
+-------------------------------+ +-+
* |
* |
* | Autres données
+-------------------------------+ |
n | Autres données | |
+-------------------------------+ +-+
Figure 41 : Format de EXCEPTION
Champs de EXCEPTION :
Adresse
L'adresse spécifie l'objet pour lequel est l'exception.
Type
C'est le type de l'exception. Les valeurs dépendent de la cible.
Autres données
Les valeurs dépendent de la cible.
Les commandes de gestion sont utilisées pour contrôler les ressources dans la machine cible. Il y a deux sortes de commandes : celles qui interrogent la machine distante sur les ressources, et celles qui allouent et libèrent les ressources. Il y a des commandes de gestion pour créer, faire la liste et supprimer les points de coupure. Toutes les commandes ont des répliques correspondantes qui comportent le numéro de séquence de la commande de demande. Les demandes qui échouent provoquent des répliques ERROR.
Il y a deux commandes d'allocation de ressources, CREATE et DELETE, qui créent et suppriment les objets dans la machine distante. Il y a un certain nombre de commandes d'énumération pour faire la liste de divers objets de la cible -- points de coupure, points d'observation, processus, et noms. La quantité de données retournées par les commandes d'énumération peut varier en longueur, selon l'état de la cible. Si une liste est trop grande pour tenir dans un seul message, la cible va l'envoyer en plusieurs listes en réplique. Un fanion dans chaque réplique spécifie si d'autres messages suivent.
La commande CREATE est envoyée de l'hôte à la cible pour créer un objet de la cible. Si CREATE réussit, la cible retourne une réplique CREATE_DONE, qui contient un descripteur associé à l'objet créé. Les types d'objets qui peuvent être spécifiés dans CREATE incluent des points de coupure, des processus, des objets de mémoire et des descripteurs. Tous sont facultatifs excepté les points de coupure.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | MANAGEMENT | CREATE |
+---------------+---------------+
2 | Type créé |
+---------------+---------------+ +-+
* |
* | Arguments
* | de CREATE
+---------------+---------------+ |
n | Arguments de CREATE | |
+---------------+---------------+ +-+
Figure 42 : Format de la commande CREATE
Champs de CREATE :
Type créé
C'est le type d'objet à créer. Les arguments varient avec le type. Les types actuellement définis sont donnés à la Figure 43. Tous sont facultatifs sauf BREAKPOINT.
Type créé |
Symbole |
0 |
BREAKPOINT |
1 |
WATCHPOINT |
2 |
PROCESS |
3 |
MEMORY_OBJECT |
4 |
DESCRIPTOR |
Arguments de Create
Les arguments de Create dépendent du type d'objet créé. Les formats de chaque type d'objet sont décrits ci-dessous.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 22 |
+---------------+---------------+
1 | MANAGEMENT | CREATE |
+---------------+---------------+
2 | BREAKPOINT |
+---------------+---------------+ +-+
3 | Mode | Argumt de mode| |
+---------------+---------------+ |
4 | | |
+-- Champ --+ | Arguments de
5 | d'identifiant | | POINT DE COUPURE
+-------------------------------+ | Create
6 | | |
+-- Décalage --+ |
7 | | |
+-------------------------------+ |
8 | États maximum | |
+---------------+---------------+ |
9 | Taille maximum | |
+---------------+---------------+ |
10| Variables locales maximum | |
+---------------+---------------+ +-+
Figure 44 : Format de CREATE BREAKPOINT
BREAKPOINT et WATCHPOINT
Le format est le même pour CREATE BREAKPOINT et CREATE WATCHPOINT. Dans l'exposé qui suit, 'point de coupure' peut être pris comme signifiant aussi bien point de coupure que point d'observation.
L'adresse est la localisation où le point de coupure doit être placé. Dans le cas de points d'observation, c'est la localisation à observer. Les modes valides sont tout mode PHYS_* qui vise une macro-mémoire, PROCESS_CODE pour les points de coupure et PROCESS_DATA pour les points d'observation.
'États maximum' est le nombre d'états qu'aura l'automate à états finis pour ce point de coupure. Une valeur de zéro indique un point de coupure par défaut, pour les cibles qui ne mettent pas en œuvre de points de coupure d'automate à états finis (FSM, finite state machine). Un point de coupure par défaut est le même que celui d'un FSM avec un seul état consistant en une commande STOP et une commande REPORT pour le processus qui contient le point de coupure.
'Taille maximum' est la taille totale, en octets, des données de point de coupure à envoyer via la commande BREAKPOINT_DATA suivante. C'est la taille des seules données, et cela n'inclut pas les en-têtes de commande LDP ni les descripteurs de point de coupure.
'Variables locales maximum' est le nombre de 32 bits à réserver aux variables locales pour ce point de coupure. Normalement, cette valeur sera zéro.
PROCESS
Crée un nouveau processus. les arguments dépendent de la cible.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | MANAGEMENT | CREATE |
+---------------+---------------+
2 | MEMORY_OBJECT |
+---------------+---------------+
3 | Taille d'objet |
+---------------+---------------+
4 | Taille de nom |
+-------------------------------+ +-+
5 | Caract du nom | Caract du nom | |
+-------------------------------+ |
* | Nom
* | d'objet
* |
+---------------+---------------+ |
n | 0 ou carac nom| 0 | |
+---------------+---------------+ +-+
Figure 45 : Format de CREATE MEMORY_OBJECT
MEMORY_OBJECT
Crée un objet de taille Taille d'objet, avec le nom donné. Taille d'objet est en unités qui dépendent de la cible. Le nom peut être la chaîne nulle pour les objets non désignés. Taille de nom donne le nombre de caractères dans Nom d'objet, et doit être pair. Se termine toujours par un octet nul.
DESCRIPTEUR
Utilisé pour obtenir des descripteurs à partir des identifiants sur les systèmes cible où les identifiants sont supérieurs à 32 bits. Il y a un seul argument, Long ID, dont la longueur dépend de la cible.
La cible envoie une réplique CREATE_DONE à l'hôte en réponse à une commande CREATE réussie. La réplique contient le numéro de séquence de la demande CREATE, et un descripteur pour l'objet créé. Ce descripteur est utilisé par l'hôte pour spécifier l'objet dans les commandes suivantes qui s'y réfèrent. Les commandes qui se réfèrent aux objets créés incluent les commandes LIST_*, DELETE et BREAKPOINT_DATA. Par exemple, pour supprimer un objet créé, l'hôte envoie une commande DELETE qui spécifie le descripteur retourné par la réplique CREATE_DONE.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 12 |
+---------------+---------------+
1 | MANAGEMENT | CREATE_DONE |
+---------------+---------------+
2 | Numéro de séquence CREATE |
+---------------+---------------+ +-+
3 | Mode | Argument mode | |
+---------------+---------------+ | Descripteur
4 | | | d'objet
+-- Champ --+ | créé
5 | d'identifiant | |
+---------------+---------------+ +-+
Figure 46 : Format de réplique CREATE_DONE
Champs de CREATE_DONE :
Numéro de séquence Create
C'est le numéro de séquence de la commande CREATE à laquelle c'est la réplique.
Descripteur d'objet créé
C'est un descripteur alloué par la cible à l'objet créé. Le contenu des champs de descripteur est alloué arbitrairement par la cible à sa convenance. L'hôte traite le descripteur comme un objet unitaire, utilisé pour se référer à l'objet créé dans les commandes ultérieures.
L'hôte envoie une commande DELETE pour retirer un objet créé par une commande CREATE antérieure. L'objet à supprimer est spécifié par un descripteur. Le descripteur est tiré de la réplique CREATE_DONE à la commande CREATE d'origine.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | MANAGEMENT | DELETE |
+---------------+---------------+ +-+
2 | Mode | Argument mode | |
+---------------+---------------+ |
3 | | | Descripteur
+-- Champ --+ | d'objet
4 | d'identifiant | | créé
+---------------+---------------+ +-+
Figure 47 : Format de la commande DELETE
Champs de DELETE :
Descripteur d'objet créé
Spécifie l'objet à supprimer. C'est le descripteur qui a été retourné par la cible dans la réplique CREATE_DONE à la commande CREATE d'origine.
La cible envoie une réplique DELETE_DONE à l'hôte en réponse à une commande DELETE réussie. La réplique contient le numéro de séquence de la demande DELETE.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | MANAGEMENT | DELETE_DONE |
+---------------+---------------+
2 | Numéro de séquence de Delete |
+---------------+---------------+
Figure 48 : Format de réplique DELETE_DONE
Champs de DELETE_DONE :
Numéro de séquence de Delete
C'est le numéro de séquence de la commande DELETE à laquelle ceci est la réplique.
L'hôte envoie une commande LIST_ADDRESSES pour demander une liste des gammes d'adresses valides pour un objet spécifié. L'objet est donné par un descripteur. Les objets sont normalement des processus cible, ou la machine physique de la cible. La cible répond par une réplique ADDRESS_LIST. Cette commande est utilisée pour obtenir la taille des espaces d'adresse dynamiques et pour déterminer des gammes de dépôt.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | MANAGEMENT | LIST_ADDRESSES|
+---------------+---------------+ +-+
2 | Mode |Argumt de mode | |
+---------------+---------------+ | Descripteur
3 | | | d'objet
+-- Champ --+ |
4 | d'identifiant | |
+---------------+---------------+ +-+
Figure 49 : Format de la commande LIST_ADDRESSES
Champs de LIST_ADDRESSES :
Descripteur d'objet
Spécifie l'objet dont les gammes d'adresse sont à énumérer. Les modes valides incluent PHYS_MACRO, PHYS_MICRO, PROCESS_CODE, et PROCESS_DATA.
La cible envoie une réplique ADDRESS_LIST à l'hôte en réponse à une commande LIST_ADDRESSES réussie. La réplique contient le numéro de séquence de la demande LIST_ADDRESSES, le descripteur de l'objet figurant sur la liste, et une liste des gammes d'adresses valides au sein de l'objet.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | MANAGEMENT | ADDRESS_LIST |
+---------------+---------------+
2 | Numéro de séquence de liste |
+---------------+---------------+
3 | Fanions |M| Compte d'item |
+---------------+---------------+
4 | |
+-- --+
5 | Descripteur |
+-- --+
6 | |
+---------------+---------------+ +-+
7 | | |
+-- Première adresse --+ | Première
8 | | | gamme
+-------------------------------+ | d'adresses
9 | | |
+-- Dernière adresse --+ |
10| | |
+-------------------------------+ +-+
*
*
*
+---------------+---------------+ +-+
| | |
+-- Première adresse --+ | Dernière
| | | gamme
+-------------------------------+ | d'adresses
| | |
+-- Dernière adresse --+ |
| | |
+-------------------------------+ +-+
Figure 50 : Format de réplique ADDRESS_LIST
Champs de ADDRESS_LIST :
Numéro de séquence de liste
C'est le numéro de séquence de la commande LIST_ADDRESSES à laquelle ceci est la réplique.
Fanions
Si M=1, la liste d'adresses se continue dans une ou plusieurs répliques ADDRESS_LIST ultérieures. Si M=0, c'est la ADDRESS_LIST finale.
Compte d'item
C'est le nombre des gammes d'adresses décrites dans cette commande.
Descripteur
C'est le descripteur de l'objet listé.
Gamme d'adresses
Chaque gamme d'adresse est composée d'une paire d'adresses de 32 bits qui donnent la première et la dernière adresse de la gamme. Si il y a des "trous" dans l'espace d'adresse de l'objet, plusieurs gammes d'adresses seront alors utilisées pour décrire l'espace d'adresses valide.
L'hôte envoie une commande LIST_BREAKPOINTS pour demander une liste de tous les points de coupure associés à la connexion actuelle. La cible réplique par BREAKPOINT_LIST.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | MANAGEMENT |LIST_BREAKPOINTS
+---------------+---------------+
Figure 51 : Format de la commande LIST_BREAKPOINTS
La cible envoie une réplique BREAKPOINT_LIST à l'hôte en réponse à la commande LIST_BREAKPOINTS. La réplique contient le numéro de séquence de la demande LIST_BREAKPOINTS, et une liste de tous les points de coupure associés à la connexion actuelle. Le descripteur et l'adresse de tous les points de coupure sont énumérés.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | MANAGEMENT |BREAKPOINT_LIST|
+---------------+---------------+
2 | numéro de séquence de liste |
+---------------+---------------+
3 | Fanions |M| Compte d'items|
+---------------+---------------+ +-+
4 | Mode | 0 | |
+---------------+---------------+ |
5 | | | Descripteur de
+-- Champ --+ | point de coupure
6 | d'identifiant | |
+---------------+---------------+ +-+
7 | Mode | Argumt de mode| |
+---------------+---------------+ |
8 | | |
+-- Champ --+ | Adresse de
9 | d'identifiant | | point de coupure
+-------------------------------+ |
10| | |
+-- Décalage --+ |
11| | |
+-------------------------------+ +-+
* | Paires
* | descripteur-adresse
* | supplémentaires
+-+
Figure 52 : Format de réplique BREAKPOINT_LIST
Champs de BREAKPOINT_LIST :
Numéro de séquence de liste
Le numéro de séquence de la commande LIST_BREAKPOINTS à laquelle ceci est la réplique.
Fanions
Si M=1, la liste des points de coupure est continuée dans une ou plusieurs répliques BREAKPOINT_LIST. Si M=0, c'est le BREAKPOINT_LIST final.
Compte d'items
C'est le nombre de points de coupure décrits dans cette liste.
Descripteur de point de coupure
C'est un descripteur alloué par la cible à ce point de coupure. Il est utilisé par l'hôte pour spécifier ce point de coupure dans les commandes BREAKPOINT_DATA et DELETE.
Adresse de point de coupure
C'est l'adresse à laquelle est établi ce point de coupure.
L'hôte envoie une commande LIST_PROCESSES pour demander une liste des descripteurs pour tous les processus sur la cible. La cible réplique par PROCESS_LIST.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | MANAGEMENT |LIST_PROCESSES |
+---------------+---------------+
Figure 53 : Format de la commande LIST_PROCESSES
La cible envoie une réplique PROCESS_LIST à l'hôte en réponse à la commande LIST_PROCESSES. La réplique contient le numéro de séquence de la demande LIST_PROCESSES, et une liste de tous les processus dans la cible. Pour chaque processus sont donnés un descripteur et une quantité de données de traitement dépendant de la cible.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | MANAGEMENT | PROCESS_LIST |
+---------------+---------------+
2 | Numéro de séquence de liste |
+---------------+---------------+
3 | Fanions |M| Compte d'items|
+---------------+---------------+ +-+
4 | PROCESS_CODE | 0 | |
+---------------+---------------+ |
5 | | | Descripteur
+-- Champ --+ | de processus
6 | d'identifiant | |
+---------------+---------------+ +-+
7 |Compte de données de traitement| |
+---------------+---------------+ |
8 | Données de traitement | |
+-------------------------------+ | Données de
* | traitement
* |
* |
+---------------+---------------+ |
n | Données de traitement | |
+-------------------------------+ +-+
* | Paires de
* | descripteur-données
* | supplémentaires
+-+
Figure 54 : Format de réplique PROCESS_LIST
Champs de PROCESS_LIST :
Numéro de séquence de liste
C'est le numéro de séquence de la commande LIST_PROCESSES à laquelle ceci est la réplique.
Fanions
Si M=1, la liste des traitements se continue dans une ou plusieurs répliques PROCESS_LIST ultérieures. SI M=0, c'est la PROCESS_LIST finale.
Compte d'items
C'est le nombre de traitements décrits dans cette liste. Pour chaque traitement, il y a un descripteur et un nombre variable d'octets de données de traitement.
Descripteur de traitement
C'est un descripteur alloué par la cible à ce processus. C'est utilisé par l'hôte pour spécifier ce PROCESS dans une commande DELETE.
Compte de données de processus
C'est le nombre d'octets de données de traitement pour ce processus. Il doit être pair.
Données de traitement
Informations qui dépendent de la cible sur ce processus. Le nombre d'octets est donné par le compte de données de processus.
L'hôte envoie une commande LIST_NAMES pour demander une liste des noms disponibles sous forme de chaînes. La cible réplique par NAME_LIST.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | MANAGEMENT | LIST_NAMES |
+---------------+---------------+
Figure 55 : Format de la commande LIST_NAMES
La cible envoie une réplique NAME_LIST à l'hôte en réponse à une commande LIST_NAMES. La réplique contient le numéro de séquence de la demande LIST_NAMES, et une liste de tous les noms cible, sous forme de chaînes.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Longueur de commande |
+---------------+---------------+
1 | MANAGEMENT | NAME_LIST |
+---------------+---------------+
2 | Numéro de séquence de liste |
+---------------+---------------+
3 | Fanions |M| Compte d'items|
+---------------+---------------+ +-+
4 | Taille de nom | |
+---------------+---------------+ |
5 | Caract de nom | Caract de nom | | Chaîne
+---------------+---------------+ | de nom
* |
* |
* |
+---------------+---------------+ |
n |0 ou carac de n| 0 | |
+---------------+---------------+ +-+
* | Chaînes de
* | nom
* | supplémentaires
+-+
Figure 56 : Format de réplique NAME_LIST
Champs de NAME_LIST :
Numéro de séquence de liste
C'est le numéro de séquence de la commande LIST_NAMES à laquelle c'est la réplique.
Fanions
Si M=1, la liste de noms se continue dans une ou plusieurs répliques NAME_LIST ultérieures. Si M=0, c'est la NAME_LIST finale.
Compte d'items
C'est le nombre de chaînes de nom dans cette liste. Chaque chaîne de nom consiste en un compte de caractères et d'une chaîne de caractères terminée par un caractère nul.
Taille de nom
C'est le nombre d'octets dans cette chaîne de nom. Elle doit être paire.
Caractères du nom
C'est une chaîne d'octets qui compose le nom. Elle se termine par un octet nul. Le nombre de caractères doit être pair, de sorte que si l'octet nul de terminaison tombe sur un octet impair, un autre octet nul est ajouté.
L'hôte envoie une commande GET_PHYS_ADDR pour convertir une adresse en forme physique. La cible retourne l'adresse physique dans une réplique GOT_PHYS_ADDR. Par exemple, l'hôte pourrait envoyer une commande GET_PHYS_ADDR contenant une adresse de décalage de registre, et la cible retournerait l'adresse physique déduite de cela dans une réplique GOT_PHYS_ADDR.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 14 |
+---------------+---------------+
1 | MANAGEMENT | GET_PHYS_ADDR |
+---------------+---------------+ +-+
2 | Mode |Argumt de mode | |
+---------------+---------------+ |
3 | Champ | |
+-- d'identifiant --+ |
4 | | | Adresse
+---------------+---------------+ |
5 | | |
+-- Décalage --+ |
6 | | |
+---------------+---------------+ +-+
Figure 57 : Format de la commande GET_PHYS_ADDR
Champs de GET_PHYS_ADDR :
Adresse
C'est l'adresse à convertir en adresse physique. Le mode peut être PHYS_REG_OFFSET, PHYS_REG_INDIRECT, PHYS_MACRO_PTR, tout OBJECT_*, et tout mode PROCESS_* sauf pour PROCESS_REG.
La cible envoie une réplique GOT_PHYS_ADDR à l'hôte en réponse à une commande GET_PHYS_ADDR réussie. La réplique contient le numéro de séquence de la demande GET_PHYS_ADDR, et l'adresse spécifiée convertie en une adresse physique.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 16 |
+---------------+---------------+
1 | MANAGEMENT | GOT_PHYS_ADDR |
+---------------+---------------+
2 | Numéro de séquence de Get |