Friedrich-Alexander-Universität Erlangen-Nürnberg  /   Technische Fakultät  /   Department Informatik
Entwicklungsumgebung f├╝r StuBS

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.