Section courante

A propos

Section administrative du site

Le débogueur

Le débogueur, le programme DEBUG.EXE proposé avec le système d'exploitation MS-DOS, tire ses origines de Tim Paterson. Ainsi, en 1980, Tim Paterson a commencé à travailler sur un système d'exploitation 16 bits pour la carte de bus 8086 S-100 qu'il avait conçue pour SCP (Seattle Computer Products) l'année précédente. Pour aider à faire fonctionner les QDOS (appelé 86-DOS), Tim a créé un débogueur dans une puce en ROM; Le code de cette version ROM a été publié dans le domaine public. Plus tard, Tim a adapté le code pour s'exécuter en tant que programme .COM sous QDOS, et a également ajouté la possibilité de démonter le code machine 8086. En attendant, Microsoft avait été occupé à acheter les droits de vendre des QDOS de Tim à IBM pour leur projet PC «secret». Tim a ensuite été embauché par Microsoft comme l'auteur principal de leur premier système d'exploitation. Lorsqu'il a terminé son travail sur le Personal Computer DOS 1.00 d'IBM en 1981, son utilitaire DEBUG.COM a été inclus avec lui. Toutes les fonctionnalités que Tim mettent dans le débogage est toujours là et peu de choses y ont été ajoutées (l'exception principale étant la commande d'assemblage; ajoutée sous DOS 2.0).

Avec la réalisation du DOS 2.0, DEBUG a gagné la possibilité d'assembler les instructions directement dans le code machine (la commande A). Il s'agit de l'une des commandes les plus importantes pour bon nombre de ses utilisateurs. Bien que manquant d'une grande partie des fonctionnalités d'un assembleur autonome, par exemple, tous les sauts doivent être aux adresses hexadécimales (aucune étiquette ne peut être utilisée), de nombreux programmes .COM utiles ont été assemblés avec cette commande. A partir de la version du DOS 3.0, la commande P (procédé à partir d'une adresse optionnelle) a été ajoutée, afin que le débogage puisse rapidement exécuter des sous-programmes; dans le même temps, il est devenu possible de tenter de passer à travers des interruptions avec la commande T (trace). Lorsque DOS a ajouter des fonctions EMS (mémoire étendue) disponibles sous DOS 4.0, les quatre commandes XA, XD, XM et XS ont également été ajoutées à Debug. Par la suite, le seul changement notable de débogage a été l'ajout de la commande d'aide (tapé un '?' à l'intérieur de débogage) sous DOS 5.0; quand toutes les commandes DOS ont finalement obtenu le /? commutateur de ligne de commande.

Les premiers pas

Pour lancer Le débogueur DEBUG.EXE, vous devez tapez la commande suivante dans l'interpréteur de commande du système d'exploitation :

debug

Au bout de quelques instant, il affiche un prompt «-». Vous entrez alors dans un interpréteur de commande, sauf que les commandes que vous entrez sont maintenant ceux reconnus par DEBUG. Vous pouvez vérifiez que vous êtes bien dedans en tapez la commande d'aide :

?

Vous aurez donc un résultat ressemblant à ceci :

Les limites du débogueur

Le programme DEBUG a été initialement conçu pour fonctionner avec des programmes .COM ayant une taille maximale de seulement 65 280 octets [(64 x 1024) - 256] ou moins; Combien moins dépendait du nombre maximal d'octets que le programme devait placer sur la pile en même temps. La soustraction de 256 octets est nécessaire car le débogage utilise souvent la zone du déplacement de 00 à FF Hex pour certaines données internes (PSP) telles que le nom du fichier chargé. N'oubliez pas que les vrais programmes .COM par définition sont censés s'intégrer dans un seul segment de mémoire (seulement 64 kib).

Même lors de l'exécution de DEBUG sous les anciennes versions du système d'exploitation Windows, car il s'agit toujours d'une ancienne application DOS en 16 bits, vous ne pouvez ouvrir que des fichiers dont les noms ont été enregistrés dans la convention 8.3 DOS; c'est-à-dire jusqu'à 11 caractères au total, en utilisant pas plus de 8 caractères DOS pour le nom et 3 pour l'extension.

Dès le DOS 1.10, le programme DEBUG a pu charger des fichiers supérieurs à 64 kib. Fondamentalement, la taille d'un fichier que débogage peut utiliser en toute sécurité sans erreur dépend de la quantité de mémoire disponible et de la façon dont le système d'exploitation gère la gestion de la mémoire.

Lorsque le débogage commence sans paramètres de ligne de commande, il effectue les opérations suivantes :

Lorsque le débogage commence par un nom de fichier (autre qu'un .exe), il effectue les opérations suivantes :

Le segment attribué au débogage dépend de la quantité de mémoire utilisée, et non de la mémoire totale disponible. Ainsi, la même machine DOS, qu'elle ait 16 ou même 4096 MIB de mémoire, chargera généralement le débogage dans le même segment; À moins qu'un programme TSR (terminate and stay resident) utilise cette mémoire, ou que la mémoire ne soit pas correctement traitée avant d'exécuter le débogage.

Utilisation de DEBUG avec des fichiers .EXE

Toute version de DEBUG de DOS 2.0 ou supérieur utilise la fonction EXEC (Interruption 21h,Fonction 4Bh) du système d'exploitation, ce qui signifie qu'il est possible pour vous d'effectuer une quantité limitée de débogage sur un programme «.EXE». Cependant, le débogage ne peut jamais être utilisé pour enregistrer un «.EXE» ou un fichier .HEX sur disque, car ces deux types de fichiers contiennent des données supplémentaires que DEBUG n'a jamais été programmée pour créer après que EXEC a supprimé ces données ! Il est tout à fait possible de modifier l'extension d'un fichier «.EXE», par exemple en .BIN, donc DEBUG peut être utilisé pour modifier un tel fichier, puis le modifier par une extension «.EXE» par la suite. Normalement, nous vous recommandons d'utiliser un éditeur hexadécimal à la place, mais nous souhaitons souligner que le débogage pourrait être utilisé avec des fichiers et des scripts de lots pour effectuer de telles modifications automatiquement; prendre la place d'un programme de correctif.

Les registres du microprocesseur 8086

Premièrement, une revue rapide de la façon dont les nombres binaires et hexadécimaux sont liés : lorsque ceux et les zéros de quatre bits binaires sont regroupés (de 0000 à 1111; souvent appelés gribouillis), ils peuvent être représentés par un seul chiffre hexadécimal (à partir de 0 à f); Les deux sont utilisés pour compter de 0 à 15 en décimal. Huit bits binaires (permettant toute valeur décimale de 0 à 255) sont représentés par deux chiffres hexadécimaux; Par exemple, le numéro binaire 10101010 est égal à AA en hexadécimal. Les numéros hexadécimaux à deux chiffres (ou nombres binaires 8 bits) sont appelés octets. Peu importe le nombre de chiffres d'un nombre en binaire ou hexadécimal, vous pouvez basculer entre les deux en regroupant et en convertissant tous les quatre bits binaires en un chiffre hexadécimal ou vice versa. L'équivalent hexadécimal d'un binaire 12 bits doit avoir 3 chiffres (par exemple, 10101011100 = ABC en Hexadécimal), et le plus grand nombre décimal pouvant être représenté par seize bits binaires (65 535) est équivalent à FFFF en hexadécimal.

Les quatre registres principaux (16 bits) d'un processeur 8086 sont appelés : l'accumulateur (AX), la base (BX), le nombre (CX) et les registres de données (DX). Chacun de ces registres a une moitié élevée (H) et faible (L) 8 bits pouvant entreposer un octet hexadécimal (1 octet = 8 bits binaires). Chacune de ces moitiés hautes et basses est accessible séparément par code de programme :

Les autres registres 16 bits (deux octets) du microprocesseur 8086 sont :

Le microprocesseur 8086 utilise une méthode de segment:déplacement chaque fois qu'il a besoin d'accéder aux emplacements de mémoire ou de passer d'un segment de 64 Ko à un autre. Il le fait en combinant deux registres 16 bits pour former un segment 20 bits : valeur de déplacement (ce qui signifie qu'il peut accéder à plus de 1 Mo de mémoire de cette façon). Pour certains types de tâches, les registres sont souvent regroupés de la même manière, mais le programmeur doit toujours s'assurer que le microprocesseur les utilisera comme prévu. Voici quelques tâches étant fixées par le microprocesseur lui-même :

Deux autres ensembles étant souvent utilisés ensemble dans les opérations de chaîne de caractères sont :

Le registre des drapeaux

Si vous souhaitez vraiment utiliser Debug dans le registre pour chaque instruction du programme que vous examinez. (Assurez-vous d'étudier le tableau final ci-dessous si vous lisez des manuels qui discutent du nouveau registre des drapeaux de 16 bits. De plus récents débogueurs 32 bits, tels que Turbo Debugger de Borland, affichent les huit drapeaux que Debug, mais utilisez une abréviation Pour le nom du drapeau et montrez simplement s'il s'agit d'un 0 ou 1 bit.)

Il s'agit d'un registre 8 bits contenant des données 1 bits pour chacun des huit drapeaux devant être interprétés comme suit :

Abréviation du manuel des noms de drapeau of df if sf zf af pf cf
Si les drapeaux étaient tous définis (1), ils ressembleraient à ceci : OV DN EI NG ZR AC PE CY
Si les drapeaux étaient tous effacés (0), ils ressembleraient à ceci : NV UP DI PL NZ NA PO NC

Voici la signification des abréviations (ce sont les mêmes que des logiciels comme CodeView) :

Drapeaux Abréviation Fixé (Bit vaut 1) Effacé (Bit vaut 0)
Débordement of OV (OVerflow) NV (No oVerflow)
Direction df DN (Down - Decrement) UP (Up - Increment)
Interruption if EI (Enabled Interrupt) DI (Disabled Interrupt)
Signe sf NG (negative) PL (positive)
Zéro zf ZR (Zero) NZ (Not zero)
Retenue auxiliaire af AC (Auxiliary Carry) NA (No AC)
Parité pf PE (Parity Even) PO (Parity Odd)
Retenue cf CY (CarrY) NC (No Carry)

Comment les drapeaux sont définis dans les registres

Le mot fixé signifie qu'un bit est défini sur 1, tandis que les mots réinitialisés ou effacés signifient un bit est défini sur 0.

Le drapeau de direction (bit 10; Fixé = Down, 0 = Up) et interruption (bit 9; set = activé, 0 = désactivé) sont quelque peu évidents. Cependant, les drapeaux suivants nécessitent une explication détaillée :



Dernière mise à jour : Mercredi, le 3 juin 2015