Der Trap-Trapper

Auf grösseren Systemen der Datenverarbeitung finden sich Teile des Betriebssystems, die über bestimmte Ereignisse eine Art Logbuch führen. Für derartige Programme wird üblicherweise der Begriff Logger verwendet, eine Standardanwendung ist z.B. das Führen einer Fehlerliste. Als Testhilfe kann das hier von mir vorgestellte Programm dienen, das die Betriebssystemaufrufe des ATARI ST über die Trap-Befehle des 68000-Prozessors protokollieren kann. Der Quellcode bietet für den Interessierten darüber hinaus einen gewissen Einblick in die Handhabung der Ausnahmebehandlungen Trace und Line-F bei diesem Prozessor.

Vor der Implementierung eines Loggers waren einige grundsätzliche Betrachtungen anzustellen, die ich vorab kurz darlegen möchte. Zunächst muß die Programmierung wegen der möglichst hohen Ausführungsgeschwindigkeit in Assembler erfolgen. Weil der Start einer solchen Anwendung meiner Meinung nach auch aus dem AUTO-Ordner heraus möglich sein sollte, entfällt - leider -eine Realisierung als Accessory. Darüber hinaus erscheint mir eine Beschränkung des Protokolls auf die drei Bereiche GEMDOS, AES und VDI als sinnvoll, da diese die mächtigsten Funktionen des Betriebssystems zur Verfügung stellen. Um die zu erzeugende Liste auch nach einem Systemabsturz mit sich anschließendem Kaltstart verfügbar zu haben, kann diese nicht im RAM, z.B. in einem Ringspeicher, geführt werden. Sie muß vielmehr dauerhaft abgelegt werden, deshalb entschied ich mich für die Ausgabe über einen am Centronics-Port anzuschließenden Drucker. Als Kennzeichnung eines Betriebssystemaufrufs genügt dafür ein Buchstabe (‘A’: AES, ‘G’: GEMDOS, ‘V’: VDI), kombiniert mit einer zweistelligen Zahl, die die Funktionsnummer hexadezimal beinhaltet. Eine auf diese Weise geführte Liste zieht allerdings, trotz der kryptischen Ausgabe, einen enormen Papierverbrauch nach sich und ist wohl auch in den wenigsten Fällen gewünscht. Deshalb mußte ich die Möglichkeit schaffen, den Ausdruck ein- bzw. auszuschalten. Zur Vereinfachung der Handhabung war zudem die Implementierung einer ebenfalls schaltbaren Zeitlupe notwendig. Auf die Steuerung dieser Funktionen über die Tastatur konnte ich verzichten, da die Möglichkeit besteht, die RS232-Schnittstelle als 2-Bit-PIO zu benutzen. Die Funktion des residenten Programms sollte außerdem durch weitere Aufrufe ausgesetzt bzw. wieder aktiviert werden können.

Die elementare Funktion des Loggers besteht darin, nach der Auslösung eines der beiden Traps die Kennung des entsprechenden Betriebssystemaufrufes auszudrucken. Diese Aufgabe kann dadurch gelöst werden, daß man die jeweils zugehörige Ausnahmebehandlung über eine entsprechende Routine umleitet. Geholt werden die relevanten Daten dann vom Stack (Trap 1) bzw. über ein Register (Trap 2). Wenn es doch nur so einfach wäre! Leider ist eine derartige Installation nicht von Dauer, das Betriebssystem des ST boykottiert ein Verbiegen des Traps 2 gelegentlich durch Überschreiben des Vektors mit einem Zeiger auf sich selbst, z.B. wenn man sich eine Textdatei über das Desktop anzeigen läßt. Vor den Erfolg setzten die Götter die Reise - durch den Speicher des ATARI ST. Nach Lösen mehrerer Fahrkarten bei verschiedenen Reiseveranstaltern bzw. Debuggern konnte ich die gesuchten Übeltäter finden. Verantwortlich für die Reinitialisierung des Vektors für Trap 2 sind Teile des GEM, die durch Auslösung der Line-F-Ausnahme aufgerufen werden. Diese Ausnahmebehandlung wird beim ATARI ST im allgemeinen Line-F-Emulator genannt. Sie wird vom Prozessor eingeleitet, sobald er erkennt, daß im nächsten auszuführenden Befehlswort - in diesem Zusammenhang mit Opcode bezeichnet - die vier höchsten Bits gesetzt sind. Von den Schöpfern des GEM wurde diese Eigenschaft des 68000 benutzt, um häufig verwendete Befehlsfolgen zu ersetzen, dazu gehören auch die Aufrufe der eben angesprochenen Routinen. Auf die Nachteile dieser Art von Programmierung wurde schon in mehreren Artikeln hingewiesen, für den Logger war sie aber durchaus nützlich. Die Arbeitsweise des Line-F-Emulators, beschränkt auf seinen für dieses Programm relevanten Teil (Listing 1), möchte ich kurz erläutern.

Der Line-F-Emulator führt zwei grundsätzlich verschiedene Funktionen aus. Ist das niedrigste Bit des Opcodes gesetzt, erfolgt die Freigabe eines Stack-Bereiches über Unlink (UNLK). Andernfalls werden die unteren drei Bytes des Opcodes - er muß glatt durch vier teilbar sein - als Offset in einer Tabelle von Startadressen diverser GEMRoutinen interpretiert. An der auf diese Weise festgelegten Stelle wird das Programm dann mit dem Ende der Ausnahmebehandlung fortgesetzt. Diese stellt vorher noch den Status des Prozessors wieder richtig. Außerdem legt sie die Wortadresse auf dem Stack ab, die dem Befehl folgt, der die Ausnahme einleitete. Bei entsprechender Programmierung kann eine Anwendung die in Frage kommenden Routinen mittels Trace feststellen und ihre unerwünschten Resultate umgehen. Bei einer Installation des so erweiterten Loggers aus dem AUTO-Ordner heraus verweigert das System jedoch beim Aufbau des Desktops unwiderruflich seine Mitarbeit. Bei genauerer Untersuchung stellte ich fest, daß nicht alle über den Line-F Emulator angesprungenen Unterprogramme im Trace-Modus durchlaufen werden können. Das Problem kann aber doch durch eine Kombination von Änderungen in den Routinen für Line-F, Trace und illegale Adresse gelöst werden. Dabei habe ich den Umstand genutzt, daß die hier interessierenden Unterprogramme mit einem Return-Befehl (RTS) abschließen. Die Ausnahmebehandlung für Line-F muß dann so erfolgen, daß bei Nutzung des Emulators als Sprungverteiler die erzeugte Rücksprungadresse illegal ist. Bei Beendigung einer auf diesem Wege angesprungenen Routine erkennt der Prozessor dann die illegale Adresse und kann den Vektor für Trap 2 gegebenenfalls wieder aufsetzen.

Genug der langen Einleitung, ich komme zur Sache (Listing 2). Der ausführbare Code beginnt wie üblich mit der Berechnung des Stackpointers und der Programmngröße, dann wird Trap 1 nachdem XBRA-Standard abgeklopft. Befindet sich das Programm schon resident im Rechner, wird sein Status geändert, und eine entsprechende Meldung erscheint auf dem Monitor. Andernfalls wird der Logger für GEMDOS eingerichtet, und das Programm bleibt nach Beendigung im Speicher. Der beim Rücksprung in das Betriebssystem ausgelöste Trap 1 führt sofort wieder in die Anwendung zum GEMDOS-Logger. Dieser besteht aus einem ersten Teil, der die Installation für Trap 2 besorgen soll, und einem zweiten, der die Protokollierung für Trap 1 erledigt. Sobald das entsprechende Bit in der Steuervariablen ein fertig installiertes Desktop anzeigt, wird der erste Teil übersprungen. Solange das aber, wie auch beim ersten Durchlauf, noch nicht zutrifft, testet das Programm, ob das Desktop läuft. Dabei wird davon ausgegangen, daß nach Ende der Boot-Phase unterschiedliche Ausnahmebehandlungen für Line-F und Trace existieren. Verläuft der Test negativ, wird bei den folgenden Aufrufen des GEMDOS geprüft, ob sowohl Line-F-Emulator als auch AES/VDI zwischenzeitlich eingebunden wurden. Sobald das Desktop dann läuft, wird der Merker gesetzt, und die Vektoren für illegale Adresse, Line-F-Emulator, Trace und Trap 2 werden geändert. Die Installation ist damit beendet, und die Aufrufe von AES und VDI werden ebenfalls über den Drucker aufgelistet.

Für die Ausgabe des Protokolls wird bei Trap 1 und auch Trap 2 dasselbe Unterprogramm benutzt. Es beinhaltet außerdem noch die Zeitlupe und läuft über das BIOS. Zur Steuerung habe ich die Eingangssignale CTS (clear to send) und CD (carrier detect) bzw. die Ausgangssignale RTS (request to send) und DTR (data terminal ready) der seriellen Schnittstelle (Tabelle 1) vorgesehen. An Elektrikteilen braucht man einen 25poligen Stecker, ein Stück 4poliges Kabel und zwei Schalter. Die Teile sind jetzt so zu verlöten, daß mit dem einen Schalter CTS und RTS, mit dem anderen CD und DTR verbunden bzw. getrennt werden können. Am Parallel-Port des MFP 68901 kann dann die Schalterstellung gelesen werden.

Listing 1: Line-F-Emulator

Tabelle 1: Belegung der RS232-Schnittstelle

Was passiert nun, wenn das Betriebssystem den Line-F-Emulator aufruft? Die modifizierte Ausnahmebehandlung prüft zunächst das niedrigste Bit des Opcodes, denn wenn der Line-F-Emulators im Unlink-Modus benutzt werden soll, kann ja ab hier wie bisher verfahren werden. Ansonsten wird der dem aktuellen Opcode-Wert entsprechende, beim Start des Loggers mit $FF vorbesetzte Merker getestet. Beinhaltet der Merker den Wert $00, so kann eine Reinitialisierung des Vektors für Trap 2 durch die zuzuordnende Routine ausgeschlossen werden; ohne Manipulationen läuft die Ausnahmebehandlung dann weiter über den Line-F-Emulator des GEM. Andernfalls wird die analog zur Vorgehens weise des Vorbildes erzeugte Rücksprungadresse auf dem Supervisor-Stack abgelegt. Anschließend wird in der Kopie des auf dem Stack abgelegten System-Bytes das Tracebit gesetzt. Schließlich kann über den gespeicherten alten Vektor der Sprung zum Original erfolgen. Hier weicht der Lauf der Dinge nur dann vom bisher bekannten ab, wenn die Kopie des Statuswortes, wie beschrieben, geändert wurde. Sobald dieses vom Stack geholt wird, um den Prozessorstatus zu restaurieren, wird der Trace-Modus eingeschaltet. Das Trace-Programm prüft ab jetzt nach jedem vom Line-F-Emulator ausgeführten Befehl, ob der auf dem entsprechenden Stack befindliche Eintrag identisch ist mit dem vorher abgelegten Rücksprungziel. Sobald dieser Zustand erreicht ist, wird das niedrigste Bit der weiterhin maßgeblichen Adresse gesetzt, die jetzt überzählige auf dem Supervisor-Stack gelöscht. Dann erfolgt die Beendigung des Trace-Modus’, und der Aufruf der gewünschten Routine schließt sich an. Nach deren Abarbeitung liest der Prozessor dann einen ungeraden Wert als Rücksprungadresse, also eine illegale Adresse. In der hierdurch ausgelösten Ausnahmebehandlung wird zuerst überprüft, ob sie durch eine Aktion des Loggers ausgelöst wurde, wenn nicht, hagelt es Bomben wie üblich. Ansonsten berichtigt die Routine entweder den Vektor für Trap 2, oder der dem soeben beendeten GEM-Teil zugeordnete Merker wird gelöscht. Dann wird das Programm an der richtigen Adresse fortgesetzt.

Zum Schluß gebe ich noch einige Anregungen zur eventuell nötigen Anpassung des Loggers an eine andere als die vorgesehene Konfiguration. Ein serieller Drucker kann relativ einfach angeschlossen werden, indem man die Stellung der Schalter über den Centronics-Port einliest. Diese Abfrage kann natürlich auch mit Hilfe einer I/O-Karte erfolgen, aber die hat ja nun mal nicht jeder. Obwohl von mir nur mit RAM-TOS bzw. Blitter-TOS auf einem Mega 1 entwickelt und getestet, habe ich die Hoffnung, daß das Programm auch mit den anderen Versionen des Betriebssystems läuft. Der kritische Punkt ist sicherlich der Test des Desktops. Das gilt vor allem für den neuen 1040 STE. Auf ihm, wie auch anderen Derivaten und zukünftigen Versionen des Betriebssystems (TOS030, PAK-68K, ...), die ohne Line-F-Emulator auskommen, kann der Logger in dieser Form nicht zum Laufen gebracht werden. Das ist der Preis, den man für eine solche Programmierung zahlen muß ... Aber ich weiß jetzt, was die Kiste beim Booten macht!

Literatur:

[1] Service Manual Mega 1, ATARI Corp.

[2] Brückmann, Englisch, Gerits, ATARI ST Intern. Data Becker GmbH Düsseldorf