grdb variables ne fonctionnant pas

Question

Je sais que c'est un peu retardé mais je ne peux pas le comprendre. Je débogage ceci:

xor eax,eax 

mov ah,[var1] 
mov al,[var2] 

call addition 

stop: jmp stop 

var1: db 5 
var2: db 6 

addition: 
add ah,al 
ret 

les chiffres que je trouve sur les adresses var1 et var2 sont 0x0E et 0x07. Je sais que ce n'est pas segmenté, mais ce n'est pas une raison pour faire de telles escapades, parce que l'appel additionnel fonctionne très bien. Pourriez-vous s'il vous plaît m'expliquer où est mon erreur?

---

Je vois le problème, je ne sais pas encore comment le réparer. La chose est, pour une raison quelconque, le pointeur d'instruction commence à 0x100 et tous les registres de segment à 0x1628. Pour répondre à l'instruction la combinaison utilisée est je devine [cs: ip] (un des registres de segment et le pointeur d'instruction pour sûr). Le décalage var1 est 0x10 (probablement à cause du début du code, il est l'octet 0x10th dans l'ordre), j'ai essayé d'examiner la mémoire et ce que j'ai été:

1628:100 8 bytes 
1628:108 8 bytes 
1628:110 <- wtf? (assume another 8 bytes) 
1628:118 ... 

tout astuces sont là dans la mémoire [ cs: var1] pointe ailleurs que dans mon code, ce qui est probablement l'endroit où l'étiquette .data traiterait probablement ds .... probablement .. je ne sais pas ce qui est supposé être à 1628: 10

---

ok, j'ai découvert ce qui a causé l'assness et m'a fait perdre toute la journée. le comportement décrit ci-dessus est juste correct, le code est entièrement fonctionnel. Ce que je ne savais pas, c'est que le débogueur grdb, pour une raison quelconque, règle l'adresse de début à 0x100 ... la solution est d'insérer la directive ORG 0x100 sur la première ligne et c'est tout. le code fonctionnait parce que le pointeur d'instruction a la bonne adresse à la première instruction et va un par un, mais votre assembleur ne sait pas quelle adresse efficace sera votre programme stocké ainsi il reste à peu près par rapport à la première ligne du code qui signifie toutes les variables (si elles n'utilisent pas l'étiquette pour la section de données) resteront pointées comme si elles commençaient à 0x0. ce qui bien sûr ne fonctionnerait pas avec DOS. et grdb émule apparemment certaines fonctionnalités DOS ... sry pour la langue, thx tout le monde pour l'effort, espérons que cela épargnera le temps de quelqu'un si ayant le même problème ...

heheh .. au moins maintenant je sais la raison pour laquelle utiliser la section .data :))))

Answer 1

En supposant qu'il s'agit d'un assemblage x86, var1 et var2 doivent résider dans la section .data.

---

Explication: Je ne vais pas expliquer exactement comment le fichier exécutable est structuré (pour ne pas mentionner c'est spécifique à la plateforme), mais voici une idée générale de savoir pourquoi ce que vous faites est ne fonctionne pas.

Le code d'assemblage doit être divisé en sections de données en raison du fait que chaque section de données correspond directement (ou presque directement) à une partie spécifique du fichier binaire/exécutable. Toutes les variables globales doivent être définies dans les sections .data car elles ont un emplacement correspondant dans le fichier binaire où se trouvent toutes les données globales.

La définition d'une variable globale (ou d'une partie globalement accédée de la mémoire) à l'intérieur de la section de code conduira à un comportement indéfini. Certains assembleurs x86 pourraient même lancer une erreur à ce sujet.