[SOS] Debogage avec bochs.

[David Decotigny]

Bonjour,

Thomas a donne les infos. Je rajouterais un petit "quick start". Avec 
bochs et qemu c'est a peu pres la meme chose, sauf qu'on n'a pas besoin 
de recompiler qemu pour ca marche. Pour des raisons de pure mauvaise 
volonte et de patience, j'utilise plutot qemu sachant qu'il faut parfois 
interpreter son comportement avec des pincettes en cas de bug :

Dans un terminal :
   qemu -S -s -fda fd.img
   (qemu attend que gdb se connecte)

Dans un autre terminal :
   gdb sos.elf
   prompt gdb> target remote localhost:1234
   prompt gdb> toutes les commandes gdb classiques avec interpretation 
symbolique (ex: break sos_kmem_cache_create, x/2w *current_kthread, etc...)

A noter que gdb ne permet pas d'observer le contenu de certains 
registres (cr0, cr2, ...). Dans ce cas, plutot que d'utiliser "info 
registers" de gdb, utiliser "info registers" dans le "monitor" de qemu 
(shift-Alt F2 ou Ctrl-Alt 2 suivant les versions).

Quand on debugge des choses bourrines avec qemu (p.ex l'init de la 
pagination), le comportement en cas de faute double ou triple est 
totalement errone, cf qemu/cpu-exec.c :
                     /* simulate a real cpu exception. On i386, it can
                        trigger new exceptions, but we do not handle
                        double or triple faults yet. */
C'est peut-etre aussi pour cette raison que des OS guest comme XP ont 
quelques problemes dans qemu. Les "pincettes" dont je parlais au debut 
concernent cette restriction.

Comme dit, bochs permet de faire la meme chose, c'est-a-dire de servir 
d'esclave a gdb. Mais bochs a aussi son debugger integre qui offre a peu 
pres les memes caracteristiques que gdb, sauf qu'il permet aussi de voir 
la valeur des registres que gdb ne connait pas (commande dump_cpu). Pour 
le debuggage symbolique, l'equivalent de "file sos.elf" de gdb est 
"load-symbols sos.map".

Bonne journee,

-- 
David Decotigny -- http://david.decotigny.free.fr