GNU Project Debugger und QEMU
Aus Lowlevel
Immer wenn eine Exception auftritt, kann man nur durch rumprobieren oder debuggen den Grund und die Stelle ausfindig machen. Durch auskommentieren und reaktivieren ist dies auf Dauer sehr nervig, deshalb wird in diesem Tutorial erklärt, wie man mit QEMU und dem GNU Project Debugger debuggen kann.
Inhaltsverzeichnis |
Grundvoraussetzungen
Man benötigt den GNU Project Debugger und QEMU. Unter Linux kann man beides über die Paketverwaltungsprogramme beziehen, während unter Windows der Debugger von Cygwin oder MinGW mitgeliefert wird und QEMU von bestimmten Internetseiten bezogen werden muss.
De Facto
Es muss von Anfang an eine Verbindung zwischen dem GDB-Server und QEMU bestehen. Dazu muss man den Terminal öffnen (unter Windows cmd.exe) und GDB den fertigen Kernel als Parameter geben.
gdb /.../kernel.bin
Der Parameter ist sehr wichtig, damit man später bei einem C-Kernel Breakpoints setzen kann. Könnte man dies nicht, müsste man den Debugger unkomofortabel benutzen. Darauf gehe ich allerdings nicht ein, da dies unbrauchbar ist und es keine wirklichen Möglichkeiten auf diese Art zum Debuggen gibt, weil die nötigen Zusatzinformationen (z.B. Funktionsnamen) fehlen. Deshalb muss man beim Kompilieren mit dem GCC-Compiler noch -g hinzufügen, damit die Informationen hinzugeschrieben werden. Nun besteht immernoch keine Verbindung. Deshalb muss man in QEMU mit Strg+Alt+2 in die Konsole wechseln und gdbserver eingeben. Zurück im Terminal ist es nun nur noch nötig target remote localhost:1234 einzutippen. Geschafft. Die Verbindung steht.
Das System wurde nachdem man den letzten Befehlen eingegeben hat abgestoppt. Nun ist es Zeit dem Debugger zu sagen, wo man nach Fehlern suchen möchte: Weiß man noch nicht, wo der Fehler ungefähr liegen könnte, sollte man nun den Befehl n benutzen, um einen Schritt im System weiter zu gehen. Das sollte man machen, bis der Fehler auftritt. Weiß man allerdings den Namen der Funktion, kann man sich die Mühe sparen und einen Breakpoint auf diese setzen:
break <Name der Funktion>
oder
break <Datei:Zeile>
Falls man weiß, wo der Fehler liegt, aber er zu früh auftritt, um die entsprechende Funktion zu debuggen, kann man call <Name der Funktion> benutzen. Dieser Befehl ruft eine Funktion auf. Man kann ihn immer benutzen, auch wenn das System schon gecrasht und QEMU dabei noch nicht abgestürzt ist.
Um Breakpoints wirklich nutzen zu können, gibt es den Befehl cont. Ruft man ihn auf, wird gewartet, bis der nächste Breakpoint beim Programmablauf zutrifft.
Man kann nach einem Breakpointtreffer nun mit n durchsteppen und mit s in die Zeile hineinspringen.
So sollte man herausfinden können, wo sich der Fehler befindet. Nun liegt es an dem Fehler selbst, was noch zu tun ist.
Befehle auf einen Blick
n = durchsteppen s = hineinspringen break <Name der Funktion/Datei:Zeile> = Breakpoint setzen call <Name der Funktion> = Funktion aufrufen p <Ausdruck> = Ausdruck auswerten und Ergebnis anzeigen bt = Stack-Backtrace anzeigen
