Affichage de la valeur trouvée à l'adresse donnée gdb

Je suis le débogage d'un fichier binaire dans gdb. C'est du code C compilé par gcc sur un processeur Intel IA-32. J'ai récupéré cette sortie de objdump. Je suis plus intéressée par la dernière ligne ici:

08048d9e <func_1>
8048d9e:    55                      push   %ebp
8048d9f:    89 e5                   mov    %esp,%ebp
8048da1:    83 ec 18                sub    $0x18,%esp
8048da4:    c7 44 24 04 88 99 04    movl   $0x8049988,0x4(%esp)
8048dab:    08 
8048dac:    8b 45 08                mov    0x8(%ebp),%eax
8048daf:    89 04 24                mov    %eax,(%esp)
8048db2:    e8 54 01 00 00          call   8048f0b <strings_not_equal>

Je crois que cette dernière ligne comparer la valeur trouvée à l'adresse indiquée: 8048f0b. Je tente:

(gdb) x 0x8048f0b

et recevez:

0x8048f0b <strings_not_equal>:  0x57e58955

Suis-je interpréter l'assemblée de façon incorrecte? Est-ce la bonne façon de lire la valeur d'une adresse dans gdb? J'ai été un peu en attendant de trouver un plus ascii amical valeur hex. Je suis intéressé à trouver la chaîne stockée la valeur qui est comparée.

Aussi avez-vous un favori interface graphique de l'outil que vous voulez utiliser pour ce type de débogage? J'ai été de penser à essayer ddd. Je veux trouver un moyen plus facile à déboguer.

OriginalL'auteur Kyle - Microsoft | 2013-01-24

  1. 19

    Vous êtes correctement la lecture de la valeur de l'adresse mémoire 0x8048f0b, mais la ligne call 8048f0b <strings_not_equal> indique que cette adresse est le début d'une fonction (appelée strings_not_equal()). Vous ne vous attendez pas que, pour être en ASCII - vous vous attendez à être de plus en code machine.

    Si vous êtes à la recherche pour les arguments de la fonction de strings_not_equal(), ceux-ci sont poussés sur la pile. Le premier argument est copié à partir de 0x8(%ebp), qui est le premier argument de func1(). Le deuxième argument est $0x8049988, qui est sans doute l'adresse d'une chaîne.

    Si vous souhaitez imprimer le contenu de l'adresse comme une chaîne de caractères, vous pouvez le faire avec x/s:

    x/s 0x8049988
    Ainsi, dans phase_1 le premier argument: 0x8(%ebp) est stocké sur la pile à %eax. Ce sera aussi un argument transmis à strings_not_equal? Comment savez-vous que le deuxième argument de strings_not_equal est $0x8049988? Est-ce parce que c'est écrit à 0x4(%esp)?
    donc x 0x8049988 donne 0x8049988 <__dso_handle+360>: 0x75742049 et x/s 0x8049988 donne une longue bizarre chaîne que je m'attends: 0x8049988 <__dso_handle+360>: "I turned the moon into something I like to call a Death Star." N'avons-nous pas besoin de 2 les valeurs hexadécimales pour représenter chaque caractère ascii? Comment se fait-il traduire cette longue chaîne de 0x75742049?
    Le premier argument de func_1() est copié à partir de 0x8(%esp) en %eax, et puis à partir de %eax sur la pile où il sera pris comme premier argument de strings_not_equal(). 0x8049988 est copié directement dans la pile, où il sera pris comme deuxième argument de strings_not_equal(). x sans n'importe quel format affiche les 4 premiers octets à l'adresse d'un entier de 32 bits; ces 4 octets sont les codes ASCII pour I (0x49), l'espace (0x20), t (0x74) et u (0x75). Comme un entier de les lire dans l'ordre inverse parce que votre machine est "little endian" .

    OriginalL'auteur caf