Für die Bearbeitung der Rechnerübungsaufgaben (und damit für die Entwicklung von StuBS) sind alle benötigten Werkzeuge im CIP installiert. Ihr könnt die Aufgaben natürlich auch zu Hause bearbeiten, wir empfehlen hierzu den Einsatz von Linux. Weiter unten finden sich einige Hinweise, wie ihr euren Linux-Rechner entsprechend konfigurieren könnt.

Achtung

Wer die Software bei sich zu Hause installieren möchte, trägt natürlich die volle Verantwortung für eventuelle Probleme. Fehlgeschlagene Installationen werden von uns auch nicht als Entschuldigung für verspätete Programmabgaben akzeptiert.

Da sich bei der Betriebssystementwicklung ab und zu auch Fehler einschleichen können, müsst ihr eure Lösungen testen, bevor ihr sie abgebt. Wir benutzen hierzu einen Emulator (QEMU) und mehrere echte Multicore-Rechner im Rechnerübungsraum. Bei der Abgabe benutzen wir immer die echten PCs, um eure Lösung zu kontrollieren. Ihr solltet deshalb immer auch mit den echten PCs testen, sie sind die Referenzplattform!

Voraussetzungen zum Kompilieren von StuBS im CIP-Pool und zu Hause

Zum Kompilieren wird wie im Makefile vorgegeben g++ verwendet, zum Assemblieren des Startup-Codes und der hardwarenahen Teilprogramme der Netwide Assembler (nasm). Der x86-Emulator QEMU eignet sich zum vorläufigen Testen und, durch einen eingebauten GDB-Stub, auch zum Debuggen mit dem GNU Debugger. Im CIP-Pool ist die entsprechende Umgebung vorhanden bzw. unter /proj/i4stubs/ gemountet; wer das Ganze zu Hause machen will, muss sich die genannte Software entsprechend einrichten. Bei Problemen könnt ihr uns gerne fragen. Andere Software (wie z.B. der LLVM C++ Compiler clang++) können zwar verwendet werden, werden aber (zumindest offiziell) nicht von uns unterstützt. Das selbe gilt auch für prähistorische GCC Versionen (< 5).

Kompilieren von StuBS

• Zu den Aufgaben gibt es eine Vorgabe. Diese ist ein Git Repository auf dem CIP Gitlab, in welches wir die Vorgabe für die einzelnen Aufgaben sukkessive einchecken.

  Um die Änderungen mit eurem Übungspartner zu teilen, könnt ihr euch einen Account auf dem Gitlab anlegen und ihm dort Zugriffsrechte gewähren.

  Achtung

  Bei gitlab.cs.fau.de muss euer Benutzername der CIP Login Name sein.

  uj66ojab@faui0sr0:~> git clone https://gitlab.cs.fau.de/i4/bs/oostubs.git
  uj66ojab@faui0sr0:~> find oostubs
  oostubs/user/
  oostubs/user/app1/
  oostubs/user/app1/appl.cc
  [...]
  

• Für die weiteren Aufgaben werden wir das Vorgabenrepository erweitern, sodass ihr euch nur die Änderungen in euer Repository ziehen müsst. Diese geänderten Vorgaben enthalten für die jeweilige Aufgabe neu hinzukommenden Dateien.
• Alle Vorgaben, die ihr von uns erhaltet, lassen sich korrekt übersetzen, enthalten aber nur unvollständigen Code. Ihr müsst also Code in den unter Aufgaben beschriebenen Funktionen und Klassen vervollständigen.
• Das eigentliche Kompilieren von StuBS erfolgt durch den Aufruf von make im Lösungsverzeichnis. Alle .cc- und .asm-Dateien im Lösungsverzeichnis werden daraufhin mit den entsprechenden Tools (Compiler bzw. Assembler) übersetzt und als bootbares Systemimage zusammengebunden. Anschließend stehen euch die Befehle make {kvm,qemu,netboot}{,-gdb}{,-noopt,-verbose} zum Testen und Debuggen zur Verfügung (mehr dazu im nächsten Abschnitt).

Testen und Debuggen von StuBS

• Als schnellsten und einfachsten Test eurer Implementierung könnt ihr mit make kvm euer Systemimage in QEMU mit Hardware-Virtualisierung ausführen:

  uj66ojab@faui04a:~/oostubs> make kvm
  

  Dabei wird QEMU standardmäßig so konfiguriert, dass er ein System mit vier Prozessoren emuliert. Für die Entwicklung von OOStuBS stört dies nicht weiter, da die zusätzlichen CPUs ohne weiteres Zutun einfach "links liegen" gelassen werden. Für die MPStuBS-Bastler gilt: durch den KVM-Modus wird euer System echt parallel auf mehreren Kernen ausgeführt. Dieser Test kommt daher im Hinblick auf Race-Conditions und fehlerhafter Synchronisation dem Test auf der echten Hardware schon relativ nahe.

• 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 (z.B, gdb) 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 kvm-gdb bereit:

  uj66ojab@faui04a:~/oostubs> make qemu-gdb
  

  In dieser Konfiguration wartet der GDB-Stub im Emulator auf eine Socket-Verbindung, über die sich ein gdb 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>
  

  Achtung

  Da durch den Emulator QEMU bei Verwendung des GDB-Stubs das Betriebssystem pausiert wird, darf man im GDB 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 den Referenz-PCs im Rechnerübungsraum gibt es das Makefiletarget netboot:

  uj66ojab@faui04a:~/oostubs> make netboot
  

  Dieses kopiert euer gebautes Systemimage auf einen TFTP-Server, so dass die Test-PCs mit Hilfe des Netzwerkbootloaders PXELinux Zugriff darauf erhalten. Die Test-PCs booten beim Einschalten automatisch aus dem Netz. Im dann erscheinenden Boot-Menü müsst ihr nur noch das aktuel;e Semester und anschließend den Eintrag mit euerem Login-Namen auswählen, um euren OOStuBS/MPStuBS-Kernel zu booten.

  Falls ihr gerade nicht im CIP seid, könnt ihr auch über die Weboberfläche mit dem Benutzer und Passwort aus der Tafelübung auf die Rechner zugreifen. Alternativ könnt ihr auch das Tool /proj/i4stubs/tools/stubs verwenden, um die Testrechner zu steuern.

  Achtung

  Versucht den Zugriff auf die Testrechner mit euren Kommilitonen abzustimmen, damit niemand beim testen unterbrochen wird. Während den Rechnerübungen sollte die Benutzungsdauer an der Hardware möglichst kurz sein.

  Sofern ihr einen passwortlosen SSH-Login (mittels Schlüssel) auf die CIP Rechner eingerichtet habt, könnt ihr ggf. nach Anpassen von der Variable NETBOOTSSH in der common.mk auch von eurem privaten PC das Makefile Target netboot nutzen.

• 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:

  uj66ojab@faui04a:~/oostubs> make qemu-gdb-noopt
  

Quellcodeverwaltung in einem gemeinsamen Git für die ganze Gruppe

Wie bereits erwähnt, ist die Vorlage zu StuBS auf gitlab.cs.fau.de zu finden. Dort habt ihr auch die Möglichkeit ein eigenes Repository anzulegen und eurem Übungspartner Zugriff darauf zu gewähren.

Eine kurze Übersicht der Git Befehle findet ihr hier. Als tieferen Einstieg in die verteilte Quellcodeverwaltung empfehlen wir das Pro Git Buch, welches als Creative Commons verfügbar ist.