next up previous contents index
Next: Liste des figures Up: gdb et la structure Previous: Les niveaux dans la

Variables et pile d'appel.

Nous allons examiner le déroulement le programme ci-dessous grâce au débogueur. Il comporte la définition d'une fonction fact , qui calcule la factorielle d'un entier positif.

#include <stdio.h>

int fact(int n)
{
  if (n==1) return 1;
  else return n*fact(n-1);
}

int main ()
{
  int a = 5;
  printf("fact(%d)=%d\n",a,fact(a));
  return 0;
}

Au moment où la fonction main fait l'appel fact(a) , n reçoit la valeur de a , qui est 5. Plaçons un point d'arrêt sur la fonction fact et lançons le programme avec r, le programme est interrompu à chaque appel à fact au niveau de la ligne << if (n==1) return 1; >>. Avançons avec step dans l'exécution de la fonction fact , après 3 appels récursifs (à elle-même), examinons la pile d'appel avec backtrace :

(gdb) bt
#0  fact (n=3) at fact.c:5
#1  0x10708 in fact (n=4) at fact.c:6
#2  0x10708 in fact (n=5) at fact.c:6
#3  0x10748 in main () at fact.c:12
La pile a 4 niveaux : les 3 appels à fact et l'appel à main .

Au niveau courant (noté 0), tentons d'imprimer la valeur de la variable a :

(gdb) p a
No symbol "a" in current context.
La variable a n'est pas définie dans ce contexte. Nous pouvons remonter dans la pile avec la commande up. Si nous allons jusqu'au niveau 3 (appel à main ) avec 3 << up >> et que nous tentons à nouveau d'imprimer la valeur de a , nous obtenons :

(gdb) p a
$3 = 5
Dans le contexte d'appel à main , la variable a est bien définie.

L'analyse au débogueur du contexte (ou environnement) d'exécution d'une fonction permet de mieux comprendre le mode de fonctionnement de C.


next up previous contents index
Next: Liste des figures Up: gdb et la structure Previous: Les niveaux dans la
R.Lalement (Cermics)