Friedrich-Alexander-Universität Erlangen-Nürnberg  /   Technische Fakultät  /   Department Informatik

Entwicklungsumgebung zu BS

F├╝r die Bearbeitung der Rechner├╝bungsaufgaben (und damit f├╝r die Entwicklung von OOStuBS und MPStuBS) 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 einen echten Multicore-Rechner im Rechner├╝bungsraum. Bei der Abgabe benutzen wir immer den echten PC, um eure L├Âsung zu kontrollieren. Ihr solltet deshalb immer auch mit dem echten PC testen, er ist die Referenzplattform!

Voraussetzungen zum Kompilieren von OOStuBS bzw. MPStuBS 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/i4bs/ gemountet; wer das Ganze zu Hause machen will, muss sich die genannte Software entsprechend einrichten. Bei Problemen k├Ânnt ihr uns gerne fragen.

Kompilieren von OOStuBS bzw. MPStuBS

  • Zu Aufgabe 1 gibt es je eine Vorgabe f├╝r OOStuBS (https://gitlab.cs.fau.de/i4/oostubs) und MPStuBS (https://gitlab.cs.fau.de/i4/mpstubs). Die Vorgaben sind Git Repositories auf dem CIP Gitlab, in die wir die Vorgaben 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.

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

    ad42resu@faui0sr0:~> git clone https://gitlab.cs.fau.de/i4/oostubs.git
    ad42resu@faui0sr0:~> find oostubs
    oostubs/user/
    oostubs/user/app1/
    oostubs/user/app1/appl.cc
    [...]
  • F├╝r die weiteren Aufgaben werden wir die die Vorgabenrepositories 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 OOStuBS 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,-ddd}{,-noopt} zum Testen und Debuggen zur Verf├╝gung (mehr dazu im n├Ąchsten Abschnitt).

Testen und Debuggen von OOStuBS

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

    ad42resu@faui48e:~/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 (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:

    ad42resu@faui0sr0:~/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:

    ad42resu@faui0sr0:~/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 OOStuBS/MPStuBS-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:

    ad42resu@faui0sr0:~/oostubs> make qemu-gdb-noopt

Quellcodeverwaltung in einem gemeinsamen Git f├╝r die ganze Gruppe

Wie bereits erw├Ąhnt, ist die Vorlage zu OOStuBS bzw. MPStuBS 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.