Testen und Debuggen von StuBSmI

Als schnellsten und einfachsten Test eurer Implementierung könnt ihr mit make kvm euer Systemimage in QEMU mit Hardware-Virtualisierung ausführen:
```
danner@faui48e:~/oostubs> make kvm
```
Dabei wird QEMU standardmäßig so konfiguriert, dass er ein System mit vier Prozessoren emuliert. Für die Entwicklung von StuBSmI stört dies nicht weiter, da die zusätzlichen CPUs ohne weiteres Zutun einfach "links liegen" gelassen werden.
Zur leichteren Fehlersuche kann die Hardware-Virtualisierung auch deaktiviert werden, indem man stattdessen den Befehl make qemu verwendet. In diesem Modus wird das Gastsystem lediglich pseudo-parallel emuliert, was bei schwerwiegenderen Bugs die Suche erleichtert, aber andererseits auch vorhandene maskieren kann, die sonst nur mit make kvm oder auf echter Hardware auftreten.
Wer bei der Fehlersuche mit einfachem "printf-Debugging" nicht weiterkommt, der kann den in QEMU integrierten GDB-Stub verwenden, um sich mit einem Debugger (gdb oder ddd) zu der Emulation zu verbinden. Auf diese Weise könnt ihr euren Betriebssystemcode bequem schrittweise ausführen, um den Grund etwaiger Abstürze oder ungewünschten Verhaltens herauszufinden. Dafür stellen wir im Makefile die Targets qemu-gdb und qemu-ddd bereit:
```
danner@faui48e:~/oostubs> make qemu-gdb
```
In dieser Konfiguration wartet der GDB-Stub im Emulator auf eine Socket-Verbindung, über die sich ein gdb oder ddd mit dem Emulator verbinden kann, um das System zu debuggen. Der Start des Debuggers wird bereits im Makefile erledigt, so dass der gdb-Prompt unmittelbar nach dem Start von QEMU im Terminal erscheint.

Eine knappe Referenz der GDB-Funktionen könnt ihr hier finden.

Wollt ihr detailierte Hinweise, wie ein bestimmter GDB-Befehl zu verwenden ist, so könnt ihr die in GDB eingebaute Hilfefunktion nutzen:
```
(gdb) help <Befehlsname>
```
Hinweis: Da durch den Emulator QEMU bei Verwendung des GDB-Stubs das Betriebssystem pausiert wird, darf man im GDB/DDD die Programmausführung nicht mit run neu anstoßen, sondern muss sie stattdessen mit continue fortführen.

Für einen schnelleren Überblick der Register- und Stackinhalte empfiehlt sich außerdem, diese gdbinit-Datei unter dem Namen .gdbinit im eigenen Home-Verzeichnis abzulegen. Diverse Ansichtsoptionen am Anfang der Datei können ganz nach dem eigenen Geschmack geändert werden.
Zum Testen auf dem Referenz-PC im Rechnerübungsraum gibt es das Makefiletarget netboot:
```
danner@faui48e:~/oostubs> make netboot
```
Dieses kopiert euer gebautes Systemimage auf einen TFTP-Server, so dass der Test-PC mit Hilfe des Netzwerkbootloaders PXELinux Zugriff darauf erhält. Der Test-PC bootet beim Einschalten automatisch aus dem Netz. Im dann erscheinenden Boot-Menü müsst ihr nur noch den Eintrag mit euerem Login-Namen auswählen, um euren StuBSmI-Kernel zu booten.
Hinweis zu Compileroptimierungen: Das Standardverhalten des vorgegebenen Buildsystems ist, das Optimierungslevel -O3 zu verwenden. Bei hartnäckigen Bugs kann der daraus entstehende Maschinencode das Debugging deutlich erschweren. Für diese Fälle gibt es alle oben genannten Makefile-Targets auch als Variante mit dem Suffix -noopt, welches die Compileroptimierungen deaktiviert. GDB-Debugging ohne Optimierungen ist beispielsweise mit diesem Aufruf möglich:
```
danner@faui48e:~/oostubs> make qemu-gdb-noopt
```