Ziel dieser Bachelorarbeit war, basierend auf einem vorhandenen Emulator, einen Debugger
für den System z Millicode zu entwickeln. Das Front-End des Debuggers war dabei in die
Entwicklungsumgebung Eclipse einzubinden.
Der Debugger ist in drei Schichten untergliedert. Die erste Schicht besteht aus
der Erweiterung der GUI der IDE Eclipse mit Hilfe von Eclipse Plug-ins.
Dazu wurde das durch Eclipse bereitgestellte Debug Framework genutzt, welches speziell das
Hinzufügen von Debugger-Erweiterungen zur IDE unterstützt.
Ein weiterer Teil ist die Erweiterung des vorhandenen Millicode-Emulators.
Beim Millicode-Emulator handelt es sich um eine Software, welche die Emulation von
IBM System z Prozessoren auf dem PC ermöglicht. Durch die vorgenommenen Erweiterungen
unterstützt der Millicode-Emulator nun auch das interaktive Debuggen des Millicodes.
Dazu stellt der Emulator eine zusätzliche Schnittstelle bereit, durch die er über das
GDB Remote Serial Protocol angesprochen werden kann.
Die dritte Schicht des Debuggers stellt die Verbindung der GUI mit dem Emulator dar.
Die separate Zwischenschicht dient hierbei zur Entkopplung der beiden anderen Teile.
Aufgaben der Zwischenschicht sind z.B. die Behandlung der Kommunikation mit dem Emulator
und die Zuordnung von Instruktionsadressen zur entsprechenden Source-Modul-Zeile.
Inhaltsverzeichnis
Vorwort
Abstract
Aufbau der Arbeit
1 Einleitung
1.1 Umfeld der Arbeit
1.2 Einordnung der Aufgabenstellung
1.3 Problemstellung
1.4 Ist-Stand
1.5 Einführung zu System z Mainframes
1.5.1 Bedeutung der System z Mainframes - Historisch und gegenwärtig .
1.5.2 System z Hardware - Überblick über die Prozessor Hardware
1.5.3 System z Firmware
2.Grundlagen
2.1 System z Millicode
2.1.1 Aufgaben des System z Millicodes
2.1.2 System z Millicode Funktionsweise
2.1.3 System z Millicode Assembler
2.2 Einführung zum Millicode Emulator
2.3 Was ist Eclipse?
2.3.1 Konzepte der Eclipse Oberfläche
2.3.2 Erweiterbares Framework hinter Eclipse
2.3.3 Extension Points
2.3.4 Deployment von Eclipse Plug-ins
2.3.5 Debug Framework
3 Anforderungen und Fachkonzept
3.1 Anforderungen
3.2 Reflexion zu den Anforderungen
3.3 Fachkonzept
3.3.1 Konfiguration einer Debug Session
3.3.2 Der Eclipse Launch Dialog
3.3.3 Bedienung während des Debuggens
3.3.4 MDB Status View
4 Systemarchitektur
4.1 Millicode Emulator Erweiterung
4.1.1 Anbindung neuer Funktionen an bestehenden MCE-Code
4.1.2 Kommunikationsschnittstelle und Kommunikationsprotokoll
4.1.3 Konzeptueller Paketaufbau
4.2 Millicode Debugger Eclipse Plug-ins
4.2.1 Aufteilung in mehrere Plug-ins
4.2.2 MDB Core Plug-in
4.3 Architektur der Connector-Schicht
4.3.1 Lösungsalternativen bei der Umsetzung des Connectors
4.3.2 Wahl der Connector-Architektur
5 Vorgehensmodell
5.1 Selektion von Methoden aus dem “Methodenbaukasten” des Agile Developments
5.2 Beschreibung des entworfenen Entwicklungsprozesses
6 Konzepte und Implementierungsdetails ausgewählter Features des Millicode Debuggers
6.1 MDB Launcher
6.1.1 Das Eclipse Launching Framework - Eine kurze Einführung
6.1.2 Implementierung des MDB Launch Delegates
6.2 Software-Design der Connector-Schicht
6.2.1 Schnittstelle zwischen Connector und MDB Core Plug-in
6.2.2 Kommunikationsablauf
6.2.3 Source Lookup
6.3 Breakpoints
6.3.1 Überblick zu Breakpoint-Typen
6.3.2 Umsetzung von Breakpoints im MCE
6.3.3 Breakpoints im GDB Remote Serial Protocol
6.3.4 Eclipse Extension zur Erweiterung von Eclipse mit eigenen Breakpoint-Typen
6.4 Register im MDB
6.4.1 Definition des Registersatzes
6.4.2 Register über den GDB Server auslesen und schreiben
6.4.3 Behandlung der Register in der GDB Server Erweiterung zum MCE
6.4.4 Interne Repräsentation eines Registers im MDB Core Plug-in
6.4.5 Anzeige der Register
7 Ausblick und Reflexion
7.1 Ausblick
7.2 Reflexion
Glossar
Literaturverzeichnis
A EPL
В Product Backlog
C Rollenverteilung
D Anhang zu Breakpoints
D. l Das Setzen von Breakpoints über das GDB Remote Serial Protocol
D. 2 Performanzmessungen
D. 3 MDBLineBreakpoint Klasse
E Anhang zum MDB Core Plug-in
E. l Ausgewählte Typen des Eclipse Debug Models
E. 2 MDB Debug Model
E. 3 Methode getThreadsQ
E. 4 Klassendiagramm zur Repräsentation der Register im MDB Laufzeitmodell
E. 5 Anwendung des Template Method Patterns im MDB Launcher
F Anhang zur Connector-Schicht
F. l Klassendiagramm des Connectors
F. 2 “IMDBConnector’-Interface
F. 3 Registergruppendefinitionen
F. 4 Connector-Refactoring
G Erweiterungen am MCE
G. l Command-Line-Parameter
G. 2 Module
H Verwendete Erweiterungen
I MDBTabGroup
J Deployment der MDB Plug-ins
Eidesstattliche Erklärung
Ich versichere hiermit an Eides statt, dass ich die vorliegende Bachelorarbeit mit dem Thema
“System z Millicode Debugger - Entwicklung eines System z Millicode Debugger Plug-ins für Eclipse basierend auf einer Anbindung an den existierenden Millicode Emulator”
selbstständig verfasst und noch nicht anderweitig für Prüfungszwecke vorgelegt habe. Alle verwendeten Quellen und Hilfsmittel sind angegeben und wörtliche sowie sinngemäße Zitate sind als solche gekennzeichnet.
(Michael Hausmann)
Danksagung
Besonders möchte ich Herrn Jakob Lang, dem IBM-Firmenbetreuer zu meiner Bachelorarbeit, für seine allzeit sehr kompetente und engagierte Unterstützung danken. Ebenfalls danken möchte ich den Professoren der Georg-Simon-Ohm Hochschule Prof. Dr. Schieder- meier und Prof. Dr. von Praun für Ihre Zusammenarbeit und für die Betreuung dieser Arbeit.
Vorwort
Heutzutage spielen Time-to-market in der IT und Effizienz in der Softwareentwicklung eine immer größere Rolle. Durch effiziente Softwareentwicklung werden die Entwicklerstunden und damit die Kosten des Softwareentwicklungsprojekts reduziert. Effektive Tools, die den Programmierer bei der Suche nach Fehlern im Programm unterstützen, tragen zum Erreichen der genannten Ziele bei und sind unter anderem auch deshalb von zunehmender Wichtigkeit. In den meisten Umgebungen stehen derartige Werkzeuge bereits zur Verfügung. Dies gilt insbesondere für die meisten Hochsprachen, zu denen meist grafische Debugger existieren, die oft darüber hinaus in einer IDE1 eingebettet sind. Für spezielle Umgebungen, wie z.B. in diesem Fall dem Millicode Assembler für die System z Firmware, ist dies jedoch (noch) nicht der Fall. Deswegen soll im Rahmen dieser Arbeit ein grafischer Debugger für den speziellen Einsatzzweck entwickelt werden, die Entwicklung des in Assembler programmierten Millicode-Teils der System z Firmware zu unterstützen.
Abstract
Ziel dieser Bachelorarbeit ist, basierend auf einem vorhandenen Emulator, einen Debugger für den System z Millicode zu entwickeln. Das Front-End des Debuggers ist dabei in die Entwicklungsumgebung Eclipse einzubinden.
Der Debugger ist in drei Teile untergliedert. Den ersten Teil stellt die Erweiterung der IDE Eclipse zur Realisierung der Oberfläche des zu entwickelnden Debuggers dar. Dazu wird im Rahmen der Arbeit das von Eclipse bereit gestellte Debug Framework genutzt, welches speziell das Hinzufügen von Debugger Erweiterungen zur IDE unterstützt. Eingebracht werden die Eclipse Erweiterungen über sogenannte Eclipse Plug-ins. Ein weiterer Aspekt der Bachelorarbeit ist die Erweiterung des vorhandenen Millicode Emulators. Beim Millicode Emulator handelt es sich um ein Programm, das die Emulation von IBM System z Prozessoren auf dem PC ermöglicht. Durch die vorgenommenen Erweiterungen unterstützt der Millicode Emulator nun auch das interaktive Debuggen des Millicodes. Dazu stellt der Emulator eine zusätzliche Schnittstelle bereit, durch die er über das “GDB Remote Serial Protocol”2 angesprochen werden kann. Der dritte Teil der Arbeit besteht in der Verbindung der Oberfläche mit dem Emulator. Eine separate Zwischenschicht dient hier zur Entkopplung der beiden anderen Teile. Hauptaufgabe der Zwischenschicht ist neben der Behandlung der Kommunikation mit dem Emulator auch die Zuordnung von Instruktionsadressen zur Laufzeit zu der Position der entsprechenden Instruktion in den Millicode Source-Modulen.
Aufbau der Arbeit
Zu Beginn der Arbeit wird zunächst auf die relevanten, bei dieser Bachelorarbeit verwendeten Technologien eingegangen. Hierzu wird die System z Serverfamilie im Kapitel 1 kurz vorgestellt. Dabei wird besonderes Augenmerk auf die System z Firmware gelegt. Die Aufgaben des Millicodes werden danach im Kapitel 2 (“Grundlagen”) beleuchtet. Im selben Kapitel werden schließlich auch der bereits existierende Emulator, auf den der Debugger aufbaut, und die Entwicklungsumgebung Eclipse, in welche die Benutzer-Oberfläche des Debuggers zu integrieren ist, vorgestellt. Zur Entwicklungsumgebung wird zuerst ein kurzer Überblick über Eclipse und dessen Konzepte aus Benutzersicht gegeben und anschließend das leistungsfähige Framework vorgestellt, das es erlaubt, die Entwicklungsumgebung als Basis für eine Vielzahl von Anwendungen zu verwenden.
Anschließend werden die Anforderungen an den zu entwickelnden Debugger beschrieben. Das Kapitel “Fachkonzept” widmet sich darauf aufbauend der Beschreibung der Funktionalität des Millicode Debuggers (MDB) aus Benutzersicht.
Im Kapitel 4 (“Systemarchitektur”) wird die prinzipielle Architektur der Debugger-Lösung mit der Untergliederung in mehrere Schichten beschrieben.
Im darauffolgenden Kapitel wird der in diesem Projekt eigens zur Realisierung von Features für den Millicode Debugger entworfene Entwicklungsprozess vorgestellt. Dieser bedient sich verschiedener Methoden aus dem “Agile Development”. Anschließend folgt eine exemplarische Beschreibung der Implementierung des MDB anhand von ausgewählten Funktionalitäten.
Kapitel 1
Einleitung
1.1 Umfeld der Arbeit
Diese Bachelorarbeit wurde bei der Abteilung “Processor Firmware Development” im Entwicklungslabor der Firma IBM Deutschland Research and Development in Böblingen angefertigt. Aufgabe der Abteilung ist die Entwicklung der Firmware für künftige Generationen der IBM System z Mainframe Systeme, sowie die Wartung der Firmware für bestehende Maschinentypen. Die System z Firmware besteht aus mehreren Schichten, welche später näher erläutert werden. Diese Arbeit befasst sich mit der Erstellung eines Debuggers für die unterste Schicht, den Millicode.
1.2 Einordnung der Aufgabenstellung
Längerfristig angestrebt ist in der Abteilung “Processor Firmware Development” die Bereitstellung einer vollständigen IDE zur Entwicklung des System z Millicodes auf den Entwicklerworkstations. Zu dieser Vision einer so genannten “Millicode Development Environment for Eclipse” gehören unter anderem ein Editor mit Syntax-Highlighting für den Millicode, ein Build-Werkzeug mit einem Cross-Assembler1 zur Erstellung von Millicode Binaries auf einer x86 Maschine und ein grafischer Debugger.
1.3 Problemstellung
Im Rahmen dieser Bachelorarbeit ist ein grafischer Debugger für die Millicode Development Environment zu erstellen. Der Millicode Debugger wird dem Benutzer die Möglichkeit einer interaktiven Fehlersuche im Millicode bieten. Als Basis für die Millicode Development Environment wurde im Millicode Team die erweiterbare Eclipse IDE ausgewählt, weshalb auch der zu entwickelnde Millicode Debugger in Eclipse integriert werden soll. Das Mittel der Wahl hierzu ist die Entwicklung eines Eclipse Plug-ins, mit Hilfe dessen die Entwicklungsumgebung um selbst entwickelte Funktionalitäten erweitert werden kann.
Um den System z Millicode auf dem PC debuggen zu können, ist selbstverständlich eine Möglichkeit zur Ausführung des Millicodes Voraussetzung. Zum Ausführen von System z Millicode auf dem PC existiert bereits ein Millicode Emulator (MCE). Der Emulator arbeitete bisher allerdings im Batch-Betrieb, d.h. ein interaktives Auslesen von Informationen oder das Setzen von Breakpoints waren beispielsweise nicht vorgesehen. Um den Emulator als Basis für das Debuggen des Millicodes verwenden zu können, müssen deshalb Erweiterungen am bestehenden Emulator-Quellcode vorgenommen werden. Dabei ist eine Anbindungsmöglichkeit zu entwickeln, so dass der MCE interaktiv von einer Benutzeroberfläche aus gesteuert werden kann.
1.4 Ist-Stand
In der Abteilung bereits vorhandene Entwicklungswerkzeuge zur Entwicklung von Millicode auf dem PC sind neben dem MCE (eine genauere Erläuterung zur bisherigen Funktionalität des MCE finden Sie in Kapitel 2.2) und einem Cross-Assembler für Millicode auch diverse Bestandteile der zukünftigen Eclipse-basierten Millicode Development Environment. Als Editor mit Systax-Highlighting wird der IBM-eigene “LPEX’-Editor verwendet. Darüber hinaus existieren Eclipse Plug-ins, die u.a. im Rahmen anderer studentischer Arbeiten in der Abteilung entstanden oder gegenwärtig in der Entwicklung sind. Ein Beispiel hierfür ist ein Plug-in, das Eclipse um einen eigenen Projekt-Typ für Millicode erweitert.
1.5 Einführung zu System z Mainframes
1.5.1 Bedeutung der System z Mainframes - Historisch und gegenwärtig .
Die Geschichte der System z Mainframes beginnt mit der Entwicklung des S/360 Mainframe in den 1960er Jahren. Ziel bei der Konzeptionierung von dessen Rechnerarchitektur war es, einen leistungsfähigen Rechner für verschiedenste Anwendungen zu entwerfen.
In Abbildung 1.1 ist der aktuelle Nachfahre des S /360 Großrechners, der System zlO EC (Enterprise Class) Mainframe abgebildet.
Abbildung in dieser Leseprobe nicht enthalten
Damals wie heute setzen vor allem Großunternehmen auf den Mainframe. Die meisten Großunternehmen, die im Fortune 1000 gelistet sind2, haben in ihren Rechenzentren eine Mainframeumgebung installiert. Aber nicht nur am Anwenderkreis kann man die Bedeutung des Mainframes festmachen. Deutlich wird dieser auch anhand des Faktums, dass ein wesentlicher Prozentsatz der im Internet verfügbaren Daten auf Mainframes gespeichert sind (Stand 2006: 60%) (nach [IBMINT06]). Traditionell die größte Bedeutung hat der IBM Mainframe bei Unternehmen aus dem Finanzsektor.
Die Nutzer von IBM Mainframes schätzen diesen vor allem wegen seiner charakteristischen Stärken. Dazu zählen beispielsweise:
- Hochverfügbarkeit (Ausfallsicherheit)3
- Hohe I/O Bandbreite
- Hohe Transaktionsraten
- Gute Skalierbarkeit
- Leistungsfähige Virtualisierungstechniken (sowohl auf Betriebssystem-Ebene mit z/VM als auch auf Firmware-Ebene)
Die hohe I/O Bandbreite und hohe Transaktionsraten versetzen eine Mainframeanwendung in die Lage sehr viele Benutzer gleichzeitig bedienen zu können.
Im modernen IT-Zeitalter immer wichtiger werden die auf dem Mainframe schon relativ lange vorhandenen, leistungsfähigen Virtualisierungstechniken. Diese ermöglichen es, den Mainframe zunehmend für Virtualisierungslösungen zu nutzten, was zukünftig zur Konsolidierung von Administrationskosten beiträgt und im Zuge der Green-IT den Energiebedarf von Rechenzentren - und damit auch die Betriebskosten - reduziert, (vgl. [ALRAD08] und [IBMWHY09])
Darüber hinaus können IBM Mainframe Kunden auch auf die Rückwärtskompatibilität neuer Mainframegenerationen vertrauen. Durch diese wird gewährleistet, dass vorhandene Applikationen auch auf neuen Maschinen weiterhin reibungslos funktionieren, was für die Kunden einen Investitionsschutz im Bezug auf ihre Anwendungen darstellt.
1.5.2 System z Hardware - Überblick über die Prozessor Hardware
In Abbildung 1.2 sind die Hardwarekomponenten der System zlO EC zu sehen, wie sie in den beiden 24” Racks, aus denen das Gehäuse der zlO EC besteht, montiert sind.
Abbildung in dieser Leseprobe nicht enthalten
Das Herzstück der System z bilden die Processor Books. Die Processor Books sind mit je einem Multi-Chip-Module (MCM), das die Processing Units (PUs) beherbergt, und mit Hauptspeicherchips (“Mainstorage”) bestückt. Die Funktion der Processor Books in Mainframes ist also vergleichbar zu der eines Mainboards in einem PC.
In Abbildung 1.3 ist ein aktuelles MCM abgebildet. Wie auch in der Abbildung zu erkennen, ist das MCM mit fünf PU Chips bestückt.
Des Weiteren sind pro MCM zwei Storage Control Chips (SCO, SCI) in der System z verbaut. Diese sind zuständig für den Zugriff auf den Hauptspeicher und den tertiären Speicher. Außerdem enthalten sie den Level 2 Cache des Processor Books, der bei der aktuellen Maschinengeration zlO bei 48 MB pro Book liegt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1.3: Multi Chip Module eines System z Processor Books - Quelle: [IBMTECH08]
Abbildung 1.4 zeigt einen aktuellen System zlO Prozessor Chip (PU). Bei diesem handelt es sich um einen Quadcore Prozessor, der mit 4,4 GHz Taktfrequenz arbeitet.
Abbildung in dieser Leseprobe nicht enthalten
Enterprise Quad Core 210 EC processor chip
Abbildung 1.4: System z Processor Chip - Quelle: [IBMTECH08]
In Abbildung 1.5 ist die System z 10 Systemstruktur im Bezug auf die Speicherhierarchie in einem Processor Book abgebildet. .Jede PU hat einen privaten Level 1 und Level 1.5 Cache von über 3 MB. Wie oben bereits erwähnt, stehen darüber hinaus 48 MB Level 2 Cache pro Book zur Verfügung. Falls die PU bei einem Speicherzugriff nicht im Cache fündig wird, müssen die Daten aus dem Hauptspeicher nachgeladen werden. Dessen maximale Ausbaustufe hegt bei der System z im Moment bei 384 GB pro Book und maximal bei 1,5 Terrabyte für den gesamten Rechner.
1.5.3 System z Firmware
Aus Sicht des Betriebssystems gehört zur System z Hardware auch noch die an die Hardware gekoppelte System z Firmware.
Layercake
Abbildung in dieser Leseprobe nicht enthalten
Processor hardware
Abbildung 1.6: System z Firmware Layercake (Quelle: [BBEHKST02])
Auf dem Diagramm (Abb. 1.6) sind die wesentlichen drei Schichten der System z Firmware abgebildet (LPAR Hypervisor, i390 code und Millicode). Die Firmware stellt das Zwischenstück zwischen der Prozessor Hardware und der Software bzw. dem Betriebssystem der System z dar. Sie wird beim Bootvorgang (im Mainframeterminus: “IPL”4 ) in einen reservierten Bereich des Hauptspeichers geladen.
Eine der standardmäßigen Virtualisierungslösungen auf IBM Mainframes sind so genannte Logical Partitions (LPARs). Mit den LPARs sieht die System z Architektur eine Virtuali- sierungsschicht bereits auf Firmware-Ebene vor. Die Verwaltung der LPARs wird von einem speziellen Teil der Firmware übernommen, dem LPAR Hypervisor, durch den die System z Mainframes eine ihrer erwähnten, charakteristischen Stärken erhalten. Die Virtualisie- rungstechniken der System z zeichnen sich auch dadurch aus, dass der LPAR Hypervisor der System z eine der sichersten Virtualisierungslösungen überhaupt bietet, was durch dessen EAL5-Zertifizierung belegt ist (vgl. [IBMADV06]). Durch LPARs wird es ermöglicht, die Serverhardware in mehrere Partitionen aufzuteilen, die jeweils einen fest zugewiesenen Bereich des installierten Hauptspeichers (beim aktuellen Modell, der zlO bis zu 384GB) belegen. In den diversen Partitionen (aktuell bis zu 60 Paritionen) können simultan mehrere, verschiedene Betriebssysteme betrieben werden.
Unter dem LPAR Hypervisor befinden sich die i390-Schicht und die Millicode Schicht. Die i390-Schicht implementiert Funktionen wie das Channel Subsystem oder Power-On Reset (nach [BBEHKST02]). Im Rahmen meiner Arbeit befasse ich mich ausschließlich mit der Millicode Schicht. Diese ist im Kapitel 2.1 genauer beschrieben.
Kapitel 2
Grundlagen
2.1 System z Millicode
2.1.1 Aufgaben des System z Millicodes
Die Hauptaufgabe des Millicodes in der System z Firmware ist die Implementierung von Instruktionen der System z Instruction Level Architecture, die nicht in Hardware implementiert sind. Zwar sind viele Instruktionen auf dem z Prozessor direkt in Hardware ’’gegossen”, jedoch wird vor allem bei meist komplexeren Instruktionen auf die Möglichkeit zurückgegriffen, die Operation nicht in einer Schaltung auf dem Prozessor zu realisieren, sondern als Bestandteil des System z Millicodes. Konzeptionell einfachere Instruktionen wie Loads, Stores, Moves und Branches werden direkt in der Hardware implementiert. Komplexere Instruktionen wie z.B. I/O Instruktionen oder Interrupt Handlers1 müssen hingegen in einer Form von internem Code implementiert werden, (vgl. [LCHELL04])
Durch Millicode wird das System mit zusätzlicher Flexibilität ausgestattet. Denn durch Millicode wird es nicht nur ermöglicht die Hardwarekomplexität zu reduzieren, indem nur ein Teil der Instruktionen in Hardware umgesetzt ist, und so mit einer geringeren Chipfläche für den Prozessor auszukommen. Darüber hinaus gewinnt man auch die Flexibilität, Hardwareprobleme, die erst spät in der Testphase des Prozessorentwicklungszyklus gefunden werden, per Firmware zu lösen, da über den Millicode Instruktionen neu definiert werden können, ohne die Hardware austauschen zu müssen, (vgl. [LCHELL04])
Im Rahmen dieser Arbeit soll eine fiktive Instruktion zur Berechnung von Faklutäten als
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: Fiktives Beispiel einer via Millicode implementierten System z Instruktion
Beispiel einer im Millicode realisierten Operation dienen. Die fiktive “FAK”-Instruktion (Fakultät) eignet sich aufgrund ihrer geringen Komplexität besser für Erläuterungen im Rahmen dieser Arbeit als reale Millicode-Routinen. Abbildung 2.1 zeigt eine beispielhafte Implementierung einer fiktiven “FAK’-Instruktion in System z Millicode.2 Im Beispiel wird die Fakultät des Integer-Werts in General Register 1 (GR1) iterativ berechnet und das Ergebnis in GR2 ausgegeben.
Die Firmware der System z trägt, unter anderem auch zu den zu Anfang des Abschnitts aufgeführten Stärken der System z Mainframes entscheidend bei. So leistet der System z Millicode z.B. auch einen Anteil zur Skalierbarkeit. der Server. Die aktuelle Maschinengeneration der System z Serverfamilie kann bis zu 80 CPs (Central Processor Kerne) beherbergen, die auch im laufenden Betrieb bei Bedarf nachträglich über ein Firmware-Update aktiviert werden können.
Eine weitere Aufgabe des Millicodes ist das “Transparent Sparing”. Dabei handelt es sich um ein Feature der System z Mainframes, welches der System z Software ermöglicht, bei Ausfall eines Prozessors (unter gewissen Bedingungen)3 ohne Beeinträchtigung weiter zu arbeiten. Transparent Sparing nutzt dabei aus, dass bei einer System z meist nicht alle Prozessoren, die auf einem Processor Book ausgeliefert werden, beim Kunden aktiviert sind. Diese inaktiven Prozessoren fungieren jedoch als “Spares”, eine Art Reserveprozessor, der bei Ausfall eines aktiven Prozessors dessen Arbeit übernehmen kann. Stellt der Millicode einen Defekt in einer aktiven PU fest, werden die Registerinhalte aus dem defekten Prozessor in einen Spare-Prozessor geladen (inklusive des Program Counters), der bis dahin inaktive Spare-Prozessor wird im Millicode als aktiv gekennzeichnet und kann nun die Arbeit des ausgefallenen Prozessors übernehmen.
2.1.2 System z Millicode Funktionsweise
Der Millicode wird beim Booten des Rechners in einen geschützten Bereich des Hauptspeichers geladen, der weder von Anwendungsprogrammen noch vom Betriebssystem aus zugreifbar ist. Jedoch wird der Millicode in vielen Fällen ähnlich wie andere Programme vom Prozessor ausgeführt. Die “I-unit” 4 des Prozessors holt die Millicode Instruktion aus dem Cache und dekodiert diese. Anschließend werden die Adressen der Operanden berechnet, diese aus dem Cache bzw. Hauptspeicher geholt und die Instruktion in der “E-unit”5 ausgeführt, (nach [LCHELL04])
Jedoch können einige Instruktionen und Register nur verwendet werden, wenn sich der Prozessor im Millicode-Modus befindet (nach [BBEHKST02]). Beispielsweise arbeiten Instruktionen, welche normalerweise die 16 allgemein sichtbaren “Program general registers” verwenden, im Millicode-Modus stattdessen auf dem entsprechenden Register aus der Gruppe der 16 “Millicode general registers” (siehe auch Tabelle 2.1). Ein Beispiel hierfür ist die in Abbildung 2.1 enthaltene Instruktion “MSGR” zur Multiplikation zweier Register.
Ansprechen des Millicodes durch die PU
Wenn der System z Prozessor beim Abarbeiten eines Programms auf eine in Millicode implementierte Instruktion stößt, wird die normale Ausführung gestoppt und der Prozessor schaltet in den Millicode-Modus um. Anschließend wird aus dem Op-Code der Instruktion die Adresse der Millicode-Routine im Hauptspeicher ermittelt und dorthin verzweigt. Nach Beenden der Millicode-Routine durch den Befehl “MCEND” wird der Millicode-Modus verlassen und die Ausführung des Anwendungsprogramms wird an der, vor der Ausführung der Millicode-Routine gesicherten, Instruktionsadresse fortgesetzt, (vgl. [LCHELL04])
2.1.3 System z Millicode Assembler
Der System z Millicode ist in einer speziellen Assemblersprache implementiert. Der Millicode Assembler ist eine Form der z/Architecture Assembler-Sprache. Jedoch können im Gegensatz zum “High Level Assembler” (HLASM), der zur Implementierung von Betriebssystemen und Anwendungsprogrammen genutzt werden kann, nur die architekturierten Befehle, die direkt von der Hardware ausgeführt werden, in Millicode-Routinen verwendet werden. Zusätzlich zu den von der Hardware ausgeführten und auf Instruction-Level- Architecture-Ebene verfügbaren Befehlen, stehen im Millicode zusätzlich rund 70 Instruktionen6, so genannte Milli-Ops, zur Verfügung, die nur angesprochen werden können, wenn sich der Prozessor im ’Millicode Mode” befindet. Im Millicode-Modus stehen außerdem auch weitere Register zur Verfügung, die von architekturierten Befehlen aus nicht zugäng-lieh sind. Häufig dienen die Milli-Ops dem Schreiben und Lesen dieser zusätzlichen Register (nach [BBEHKST02]). In Tabelle 2.1 ist, zur Demonstration der Millicode-Sicht auf die Register, der Registersatz der System z990 abgebildet. Im HL ASM stehen vom kompletten Registersatz lediglich die Gruppe der Program general registers (GR), Program access registers (AR) und Floating-point registers (FPR) dem Programmierer zur Verfügung.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.1:Registersatz der System z990
Diese Millicode-spezifischen Erweiterungen in der Assemblersprache machen den Millicode zu einer ganz speziellen Anwendungsdomäne und sind der Grund, warum keine Standardprodukte, die das Debuggen von System z Assembler Programmen erlauben, in der Firmware-Entwicklung eingesetzt werden können. Denn wäre der Millicode im Anwendungsmodus ausführbar, wäre ein Debugging mit Hilfe eines verfügbaren HLASM Compilers und Debuggers im Rahmen eines Testprogramms denkbar.
Build Prozedur
Zum Assemblieren des Millicodes wird ein handelsüblicher HL ASM-Assembler verwendet. Die zusätzlichen Milli-Ops sind über Assembler-Makros realisiert, welche aus der Mnemonic Schreibweise der Milli-Ops die entsprechende Maschineninstruktion mit dem richtigen OpCode generieren.
Die einzelnen Funktionen bzw. die im Millicode implementierten Instruktionen sind auf separate Source-Module verteilt. Beim Erzeugen des Millicodes wird jedoch, historisch bedingt, eine große Input-Datei für den Millicode Assembler aus allen Quelldateien erzeugt.
2.2 Einführung zum Millicode Emulator
Der Millicode Emulator (MCE) ist ein existierendes Programm zur Emulation der System z Prozessor Hardware. Der Emulator wird vorwiegend auf den Entwicklerrechnern eingesetzt, um den Millicode zu testen. Er kommt dabei früh im Entwicklungszyklus eines neuen Prozessor zum Einsatz. Er ermöglicht es, Millicode bereits vor der Fertigstellung der Hardware zu testen und trägt so zu einer Qualitätsverbesserung des Millicodes bereits vor dem Testen auf der realen Hardware bei, was Testaufwand einspart und den Entwicklungszyklus beschleunigt.
Bisher arbeitet der MCE im Batch-Modus, wodurch den Entwicklern zur Fehlersuche lediglich die Informationen zur Verfügung stehen, die der MCE während des Testlaufes protokolliert und am Ende in eine Datei ausgibt. Im MCE-Output, der Informationen zum gesamten Testcase enthält, müssen die benötigten Informationen in einer großen Datenmenge (bis zu mehreren Gigabytes) erst lokalisiert werden. Ein interaktives Debuggen über einen grafischen Debugger nimmt den Entwickler hier Arbeit ab, da immer nur der aktuelle Zustand der Maschine betrachtet wird.
Es folgt eine kurze Beschreibung des Inputs und Outputs des MCE. Als Input für den MCE werden folgende Dateien benötigt (grafische Übersicht in Abbildung 2.2):
- Millicode Binary
- Control File
- Testcase File
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2: Überblick über MCE Input- und Output-Dateien
Das vom MCE ausgeführte Millicode Binary (auch Millicode Load genannt), ist dabei identisch zu dem Binary, das in der System z Firmware auf der Maschine eingesetzt wird. Es enthält also insbesondere keinerlei zusätzliche Debugging-Informationen.
Im Control-File werden im Wesentlichen die Eigenschaften der zu emulierenden Maschine für den Testcase fest gelegt.7
Das Testcase-File, das der MCE als Input verarbeitet, ist eine Datei im IBM-eigenen AVP-Format8. Es enthält einen oder mehrere komplette(n) Testcase(s) mit je einem Maschinenprogramm, dessen Eingabewerten und Soll-Ausgabe-Werten. Konkret sind in dem Testcase-File ein Testprogramm bzw. Programmteil als compiliertes Maschinenprogramm in Hex-Darstellung, sowie alle nötigen Registerinhalte und Eingabedaten im Arbeitspeicher definiert. Letzteres garantiert, dass der Code immer in einer definierten Umgebung läuft. Am Ende des Testcases sind schließlich die Sollwerte für Register- und Arbeitsspeicherinhalte gegeben, so dass mittels eines automatischen Vergleichs im MCE nach Ausführung des Testcases überprüft werden kann, ob dieser erfolgreich abgeschlossen wurde.
Der Output des MCE, der die Informationen über den Verlauf des Testcases enthält, besteht aus zwei Dateien, dem Report File und dem Trace File. Bei eingeschaltetem Tracing legt der MCE im “Trace File” Informationen zu den ausgeführten Instruktionen sequentiell ab, d.h. z.B. beim dreimaligen Durchlaufen einer Schleife wären die Instruktionen aus dem Schleifenrumpf auch dreimal enthalten.
Das “Report File” enthält das Ergebnis des Testcases und gibt z.B. Auskunft über die Anzahl an verarbeiteten Instruktionen und über Abweichungen zum Soll-Zustand am Ende der Emulation.
Funktionsweise des MCE
Nach dem Initialisieren des Millicode Emulators mit den Werten aus dem Control File und dem Laden der Millicode Load und des Testcase Files, startet der MCE mit der Ausführung des Testprogramms, das im Testcase File spezifiziert wurde. Dazu startet der MCE die Ausführung an der Adresse, auf die das aktuelle Program Status Word verweist, das ebenfalls im Testcase File definiert ist. An der Adresse wird eine HL ASM Anweisung erwartet, die im MCE dekodiert und anschließend ausgeführt wird.
Der MCE Prozess besteht zur Laufzeit nur aus einem Thread (single threaded). Dabei können in diesem einen Thread auch mehrere PUs emuliert werden. Dazu wird in einem Round-Robin-Verfahren auf jeder PU nacheinander eine Instruktion ausgeführt (vgl. [BBEHKST02]).
Beim Ausführen wird zwischen in Millicode implementierten und in Hardware implementierten Operationen unterschieden. Handelt es sich um eine Operation, die der z Prozessor in Hardware implementiert, wird diese vom MCE direkt ausgeführt. Handelt es sich um eine Operation, die im Millicode implementiert ist, verzweigt der MCE zu der Einsprungadresse der entsprechenden Operation in der Millicode Load. Er arbeitet dabei analog zum realen Prozessor und berechnet die Einsprungadresse der Instruktion aus dem Op-Code der Instruktion.
2.3 Was ist Eclipse?
Viele Softwareentwickler kennen Eclipse als eine Open Source Entwicklungsumgebung, die vor allem für die Entwicklung von Java Programmen populär ist. Das trifft zu, jedoch ist Eclipse wesentlich mehr als nur eine Entwicklungsumgebung. Eclipse bietet vor allem ein leistungsfähiges Framework zur Erweiterung der Eclipse Workbench9 und damit zur Erstellung von IDEs und anderen Anwendungen.
Die Eclipse Plattform wurde ursprünglich von IBM entwickelt. Nachdem IBM Eclipse unter der IBM’s CPL (Common Public License) veröffentlichte, ist daraus ein Open Source Projekt entstanden, (nach [GALL02]) Inzwischen steht Eclipse unter der EPL (Eclipse Public License). Details zu den Konsequenzen, die sich daraus ergeben, sind im Anhang unter A erläutert. Im Rahmen dieser Bachelorarbeit wurde basierend auf einem Teil von Eclipse, dem Debug Framework, ein Debugger Front-End entwickelt. Deshalb sollen an dieser Stelle zuerst die Oberfläche sowie die Bedienkonzepte von Eclipse kurz vorgestellt werden, um eine Basis für die anschließende Vorstellung des Frameworks zur Erweiterung von Eclipse zu schaffen.
2.3.1 Konzepte der Eclipse Oberfläche
In Eclipse arbeitet der Benutzer auf einem so genannten Workspace. Im Workspace sind nun ein oder mehrere Projekte enthalten, die wiederum mehrere Unterverzeichnisse und Dateien haben können.
Es können verschiedenartige Projekte in einem Workspace angelegt werden. So können auch Millicode-Projekte bzw. ein “MDE Project” im Workspace angelegt werden. Beim Arbeiten mit Eclipse steht dem Benutzer typischerweise ein Editor, der von mehreren Views umgeben ist, zur Verfügung. Ein Beispiel für einen Editor ist der bekannte Eclipse Java Editor, der zum Schreiben von Java Programmen eingesetzt wird und dazu den Entwicklern spezielle Unterstützung, wie z.B. ein Syntax-Highlighting für Java, bietet. Im Editor sind auch Features wie z.B. das Setzen und Anzeigen von Breakpoints umgesetzt. Dabei werden sogenannte “Breakpoint Markers” verwendet. (Ein Marker erscheint mit einem zum Marker gehörenden Symbol am linken Rand des Editors.) Als Beispiele für Views sind in der Abbildung 2.3 die Console View und die Package Explorer View zu sehen. Die Eclipse Workbench kann sowohl mit eignen Editoren als auch neuen Views erweitert werden.
Die Kombination verschiedener Views und Editoren wird als Perspektive bezeichnet, (nach [CLRU04, Seite 5]) In einer Perspektive ist das Layout der Views, das durch die Anordnung der verschiedenen Views um den Editor herum entsteht, abgespeichert. Standardmäßig bietet eine Perspektive eine vordefinierte Auswahl von Views und zeigt diese in einem
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.3: Eclipse Workbench
vordefinierten Layout an. Verändert der Benutzer das Layout der Perspektive, wird das neue Layout für die Perspektive im Workspace abgespeichert und steht so beim nächsten Offnen der Perspektive in dem Workspace wieder zur Verfügung. Das Symbol der aktiven Perspektive erscheint in der oberen rechten Ecke des Eclipse Fensters, (nach [CLRU04, Seite 5]) Für Millicode-Projekte existiert ebenfalls bereits eine “MDE Perspective”. Eine weitere Perspektive, die “Debug Perspektive” wird automatisch von Eclipse beim Starten einer Debug Session über das Eclipse Debug Framework geöffnet.
2.3.2 Erweiterbares Framework hinter Eclipse
Die Erweiterung von Eclipse über Eclipse Plug-ins ist zentraler Bestandteil der Eclipse Architektur. Praktisch alle Funktionen in Eclipse sind mittels Plug-ins implementiert (mit Ausnahme eines relativ kleinen Run-time Kernels). Das ermöglicht es auch zwei verschiedene Eclipse-Instanzen mit völlig unterschiedlicher Funktionalität auszustatten. Zwei unverzichtbare Plug-ins stellen jedoch das “Workbench”- und “Workspace”-Plug-in dar, die praktisch immer vorhanden sind und auf denen andere Plug-ins basieren. Die Workbench- Komponente bietet Erweiterungsmöglichkeiten (sogenannte Extension Points - siehe auch
Abschnitt 2.3.3), die es z.B. erlauben, in Plug-ins das Eclipse User Interface mit eigenen Menüs oder Views zu erweitern. Die Workspace-Komponente enthält Extension Points, um mit Ressourcen wie Projekten und Dateien zu interagieren (nach [GALL02]). Neben den Workbench und Workspace Plug-ins stellt Eclipse standardmäßig auch ein Debug Plug-in bereit, das durch eigene Plug-ins erweitert werden kann. Diese Möglichkeit wird für diese Arbeit genutzt und im weiteren Verlauf der Arbeit beschrieben.
Zur Erstellung von Eclipse Plug-ins in der Programmiersprache Java wird üblicherweise wiederum Eclipse als Entwicklungsumgebung verwendet, da hierin eine gute Werkzeugunterstützung für diese Aufgabe gegeben ist. Beispielsweise stellt Eclipse zum Anlegen eines Eclipse Plug-in Projekts dem Entwickler einen Wizard zur Verfügung, der ein neues Plug-in Projekt im Workspace erstellt und die nötigen Dateien erzeugt. Ein Eclipse Plug-in Projekt besitzt im Vergleich zu einem normalen Java Projekt für Java Applikationen folgende zwei Dateien als zusätzliche Bestandteile:
- MANIFEST. MF
- plugin.xml (siehe Abschnitt 2.3.3)
In der Datei MANIFEST.MF sind Metainformationen zu einem Plug-in abgespeichert. In Tabelle 2.2 sind einige häufig verwendete Metainformationen aufgelistet. Ein Beispiel zu Metainformationen in der MANIFEST.MF ist in der Abbildung 2.4 zu sehen.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.2: Metainformationen in der MANIFEST.MF Datei
Die Default ActivationPolicy bei Eclipse Plug-ins ist “Lazy”, d.h. die Klassendefinitionen der Plug-ins werden erst bei Bedarf nachgeladen. Beim Starten von Eclipse werden dabei nur die Manifestinformationen aus der MANIFEST.MF und der plugin.xml (siehe unten) gelesen. Dadurch werden lange Ladezeiten beim Programmstart vermieden.
Die in der MANIFEST.MF nach Require-Bundle angegebenen Plug-ins stellen die Abhängigkeiten des Plug-ins dar. Im Gegensatz zum “Java build path” gelten die Angaben bei Require-Bundle nicht nur für die Compile-Zeit sondern auch zur Laufzeit. Bei dem
Import-Package Abschnitt handelt es sich schließlich um eine alternative Form der Angabe, hier werden keine Plug-in Namen, sondern Java Packages angegeben, zu denen das zu implementierende Plug-in eine Abhängigkeit besitzt, (vgl. [CLRU04, Seite 74])
Die Deklaration der Abhängigkeiten wird von Eclise auch verwendet, um sicherzustellen, dass keine Plug-ins mit fehlenden Abhängigkeiten ausgeführt werden. Ist ein benötigtes Plug-in zur Laufzeit nicht, vorhanden, wird das abhängige Plug-in von Eclipse gar nicht erst geladen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4: MANIFEST.MF
Die Datei plugin.xml enthält eine Beschreibung der im Plug-in erweiterten Extension Points im XML-Format. (Abbildung 2.5 zeigt als Beispiel die Erweiterung mit einem eigenen Breakpoint Typ.) Das Konzept der Extension Points wird im folgenden Unterkapitel genauer erläutert.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.5: Ausschnitt aus der plugin.xml
Werden vom Plug-in keine Extension Points erweitert, z.B. weil das Plug-in ausschließlich Methoden als Dienste für andere Plug-ins bereitstellt, ohne selbst direkt von der Eclipse Umgebung aufgerufen zu werden, benötigt das Plug-in nur eine MANIFEST.MF Datei. Eine plugin.xml Datei wird in diesem Fall nicht benötigt.
2.3.3 Extension Points
Extension Points werden vom Eclipse Framework (bzw. von Eclipse Plug-ins) bereit gestellt, um dessen Funktionalität zu erweitern. Die in einem Plug-in vorgenommenen Erweiterungen sind (wie oben bereits erwähnt) in der Datei plugin.xml definiert. Um einen Extension Point zu erweitern, ist in der plugin.xml ein extension-Tag nötig. In Abbildung 2.5 sieht man beispielhaft die Erweiterung des Extension Points org. eclipse, debug, core, breakpoints. Dieser Extension Point wird vom Plug-in org. eclipse.debug, core bereitgestellt und dient dazu, Eclipse mit selbst definierten Breakpoint-Klassen zu erweitern. Im inneren Tag breakpoint wird im Attribut dass der Name der Klasse definiert, die den neuen Breakpoint-Typ implementiert. Diese Klasse hat das Interface IBreakpoint zu implementieren.
Weitere Attribute sind name, das den Namen des neuen Breakpoint-Typs enthält, markerType, das die ID zum zugehörigen Breakpoint Marker enthält, dessen Icon nach dem Setzen des Breakpoints im Editor an der linken Seite vor dem Code erscheint und das id- Attribut, das von vielen Extension Points benötigt wird und eine eindeutige ID zu dieser Erweiterung enthält.
2.3.4 Deployment von Eclipse Plug-ins
Um ein Eclipse Plug-in in einer Eclipse-Instanz zu installieren, muss lediglich das Plug-in im Unterverzeichnis plugins der Eclipse-Instanz abgelegt werden. Dies kann wahlweise in Form eines Unterordners oder als .jar Datei (Java Archiv) geschehen. Wird das Plug-in in Form eines Unterordners in das plugins-Verzeichnis kopiert, liegen darin die kompilierten .dass Dateien und zusätzlich die Dateien MANIFEST.MF und plugin.xml. Die .dass Dateien, die den Java Bytecode des Plug-ins enthalten, sind dabei in einem Java Archiv zusammengefasst.
Der Name des jar Files sollte bei der zweiten Alternative so aufgebaut sein: <bundle-name>_ <version>.jar
Diese Konvention erleichtert Benutzern die Verwaltung von mehreren Plug-ins und unterschiedlicher Plug-in Versionen, die in einer Eclipse Instanz installiert sind.
Ein sehr komfortables Feature von Eclipse ist das Installieren und Updaten von Plugins über eine Update Site. Die Funktion kann über den Menüeintrag иНе1р”->‘Во^и}аге Updates”... aufgerufen werden. Die Funktion ermöglicht es dem Benutzer Plug-ins, die
URL bzw. den lokalen Pfad zu mehreren Update Sites zu speichern, die über eine Update Site veröffentlichten Plug-ins aufzulisten und zu installieren.
Weitere Ausführungen zum Deployment sind im Anhang unter J zu finden.
2.3.5 Debug Framework
Ein grafischer Debugger zur Unterstützung beim Testen und bei der Fehlersuche gehört in der modernen Softwareentwicklung zu den Standardwerkzeugen. Deshalb ist eine der Hauptaufgaben beim Einbinden einer neuen Sprache in die Eclipse Plattform das Hinzufügen einer Möglichkeit diese Programme zu debuggen. (nach [DAWR04, Seite 1])
Um das zu vereinfachen, bietet die Eclipse Plattform eigens hierfür ein Debug Framework. Mit dessen Hilfe können Standardwidgets10 der Eclipse Workbench wiederverwendet werden.
Das Eclipse Debug Model
Um das Eclipse Debug Framework zur Implementierung eines Debuggers zu verwenden, muss ein Laufzeitmodell des zu debuggenden Programms implementiert werden. Dazu bietet Eclipse mit dessen Debug Model Basistypen und -klassen, die vom konkreten Debugger implementiert und erweitert werden.
Die Abbildung E.l im Anhang zeigt ein UML Diagramm der Klassen des Eclipse Debug Models, die im MDB verwendet werden.11 Im Anhang ist auch die Bedeutung der wichtigsten Typen im Debug Model kurz erläutert. Um die Struktur des Debug Models zu verstehen, sollte man bedenken, dass das Eclipse Debug Model von einer Hochsprache als verwendete Programmiersprache beim zu debuggenden Programm ausgeht. Im Debug Model sind deshalb Threads als nebenläufige Instanzen und Stackframes als Laufzeitdatenstruktur zur Verwaltung der Funktionsaufrufhierarchie vorgesehen.
Kapitel 3
Anforderungen und Fachkonzept
Im ersten Teil dieses Kapitels werden die Anforderungen an die Funktionalität des MDB vorgestellt und es wird reflektiert, wie die Anforderungen an das Projekt mit den Gegebenheiten, die Eclipse bietet, zusammenpassen. Der zweite Teil beschäftigt sich mit der Beschreibung des Bedienkonzepts zum Millicode Debugger. Das umfasst sowohl die Erfassung von Konfigurationsdaten für den Debugger vor dem Start einer MDB Debug Session als auch die Benutzung des Debuggers während der Debug Session.
3.1 Anforderungen
Im Folgenden sind die aus Anwendersicht gestellten Anforderungen an den im Zusammenhang mit dieser Arbeit zu entwickelnden Debugger erläutert.
Übersicht über die Anforderungen an den Millicode Debugger:
1. Integration in Eclipse
2. Single Step
3. Setzen und Löschen von Breakpoints
4. Anzeige der im Test vorhandenen PUs
5. Synchronisation von Debugger und Editorfenster
6. Auslesen und Verändern von Registerinhalten und Main Storage (Hauptspeicher)
7. Unterstützung der Betriebssysteme Linux und Microsoft Windows
8. Konfiguration des Debuggers direkt in Eclipse
Erläuterung der Anforderungen:
1. Integration in Eclipse
Wie schon in der Einleitung erwähnt, muss der MDB in Eclipse integriert werden, da die Millicode Development Environment auf Eclipse aufsetzen soll. Der Debugger soll dabei vollständig in die Eclipse IDE eingebettet sein, so dass der Benutzer die Funktionen des MDB zusammen mit Funktionen anderer Eclipse Plug-ins nutzen kann. So soll beispielsweise das Setzen von Breakpoints im gleichen Editorfenster möglich sein, wie das von einem anderen Plug-in durchgeführte Anzeigen von Tooltips zu im Millicode verwendeten Konstanten.
2. Single Step
Uber die Single Step Funktion ist es einem MDB Benutzer zu ermöglichen, die Ausführung bis zur nächsten Instruktion fortzusetzen. Als nächste Instruktion wird dabei die in der jeweiligen PU direkt anschließend ausgeführte Instruktion verstanden.
Bei einem Single Step muss in der Oberfläche also auch die Möglichkeit berücksichtigt werden, nach einer Branch Instruktion an eine anderen Stelle im Source-Modul oder auch in ein anderes Source-Modul zu verzweigen. Die Single Step Funktion des MDB ähnelt damit der aus anderen Debuggern bekannten “Step Into” Funktion.
3. Setzen und Löschen von Breakpoints
Das Setzen und Löschen eines Breakpoints zu einer Instruktion muss in dem zum Schreiben von Millicode Assembler-Programmen verwendeten LPEX-Editor möglich sein und ist direkt in der zur Instruktion gehörenden Zeile im Source-Modul zu ermöglichen. Das bei einem Breakpoint-Hit geforderte Verhalten sieht vor, die Ausführung im MCE für alle PUs zu unterbrechen, bis die Ausführung vom Benutzer fortgesetzt wird.
4. Anzeige der im Test vorhandenen PUs
Bei der Verarbeitung eines Testcase im MCE können auch mehrere PUs emuliert werden. Um die Anzahl der für einen Testcase vorhandenen PUs dem Benutzer ersichtlich zu machen, sind deshalb in der Debugger-Oberfläche alle vom MCE emulierten PUs aufzulisten. Weiterhin soll die Auswahl einer PU möglich sein, wodurch im Editorfenster an die Stelle im Millicode Quellcode gesprungen wird, die der aktuell von der markierten PU ausgeführten Instruktion entspricht.
5. Synchronisation von Debugger und Editorfenster
Beim Unterbrechen der Ausführung nach einem Breakpoint Hit oder Single Step ist im LPEX-Editorfenster zur entsprechende Zeilen im entsprechenden Modul des Millicode Quellcodes zu springen.
6. Auslesen und Verändern von Registerinhalten und Main Storage (Hauptspeicher)
Es ist eine Möglichkeit zu schaffen alle Register- und Hauptspeicherinhalte während des Debuggens auszulesen und anzuzeigen. Des Weiteren ist das Verändern von Registerinhalten und Hauptspeicherbereichen zu unterstützen.
Da der z Prozessor zahlreiche Register besitzt (mehrere hundert Register pro PU) sollen die Register in Gruppen unterteilt werden, so dass der Benutzer die Möglichkeit hat, nur einen Teil der Register zum Anzeigen auszuwählen.
Des Weiteren sind zu den Registern zusätzlich zu deren Namen die Registernummern und Alias-Namen (alternativer Name des Registers) anzuzeigen. Dieser Alias muss dabei für jede Eclipse-Instanz unabhängig festlegbar sein, um es zu ermöglichen, dass verschiedene Entwickler unterschiedliche Alias-Namen für ein Register verwenden. Als anzuzeigende Registernunnner soll die MCE-interne Nummer des Registers verwendet werden, die sich nach dem Registerlayout des Prozessors richtet. Bei dem Register MCRO (dem ersten Register aus der Gruppe der Millicode Control Registers) wäre das z.B. (ausgehend vom Registerlayout des z990 Prozessors) Registernummer 0x40.
7. Unterstützung der Betriebssysteme Linux und Microsoft Windows
Da sowohl Linux als auch Microsoft Windows als Betriebssystem auf den Entwicklerrechnern verwendet wird, sind vom MDB beide Plattformen zu unterstützen. Dieser Anforderung kommt entgegen, dass der in der Programmiersprache “C” implementierte MCE, auf den die Debugger-Lösung aufbaut, bereits für beide Betriebssysteme verfügbar ist und dass die Portabilität der Eclipse Plug-ins durch die einzusetzende Programmiersprache Java (bzw. die Verfügbarkeit einer Java Runtime für beide Systeme) unterstützt wird.
8. Konfiguration des Debuggers direkt in Eclipse
Die Konfiguration einer Debug Session mit dem Setzen der zum Starten des Debugging nötigen Parameter soll neben dem eigentlichen Debugger ebenfalls in Eclipse integriert werden.
3.2 Reflexion zu den Anforderungen
Durch Betrachtung der vom Eclipse Debug Framework gebotenen flexiblen Erweiterungsmöglichkeiten wird die hervorragende Eignung von Eclipse als Basis zur Realisierung eines MDB Front-Ends mit den in Kapitel 3.1 geforderten Eigenschaften deutlich.
Zum einen bietet Eclipse über das Debug Plug-in wiederverwendbare Widgets. Dazu zählt z.B. die Register View zur Anzeige von Registergruppen und Registerinhalten, sowie die
Breakpoint View zur Auflistung aller in einem Projekt existierenden Breakpoints. Ebenfalls sehr gut wiederverwenden lässt, sich die Memory View. Über sie kann der Anwender Hauptspeicherbereiche auslesen und verändern.
Zum anderen bietet Eclipse auch mit dem Debug Model (siehe Kapitel 2.3.5) eine Vorlage zur Implementierung eines Laufzeitmodells des zu debuggenden Programms, welches im Allgemeinen eine zentrale Komponente der auf Eclipse basierenden Debugger darstellt. Das Eclipse Debug Model lässt sich sehr gut zur Realisierung des MDB wiederverwenden. Es bietet für viele der nötigen Abstraktionen bereits Basisklassen an. Das Debug Model ist außerdem flexibel genug, um nicht, zwingend alle Basistypen, die das Model anbietet., im MDB implementieren zu müssen, so dass nur die im Kontext des Millicode Debuggers relevanten Komponenten erweitert, werden können.
An einem Punkt ist. eine Abwandlung des Debug Models nötig. Da das Debug Model beim zu debuggenden Programm von einem in einer Hochsprache implementierten Programm ausgeht, sind Abstraktionen für Stackframes und Threads vorgesehen. Diese Annahme trifft beim Millicode Debugger nicht, zu. Jedoch gibt, es im Kontext, des Millicode auch nebenläufige Einheiten. Dies sind jedoch nicht Threads, sondern die emulierten PUs. Um die PUs im Debug Model darzust.ellen, wird deshalb das Interface “IThread” des Debug Models implementiert.
Die Anforderung der Anzeige der vorhandenen PUs kann sehr gut. mit. der “Debug View” realisiert werden. Die vom Eclipse Debug Plug-in zur Verfügung gestellte “Debug View” wird vom Debug Framework mit den aktiven Debug Sessions, deren zugeordneten Betriebssystemprozessen und den zugeordneten Instanzen mit den Typen “IDebugTarget”, “IThread” und “ISt.ackFrame” gefüllt.. In Abbildung 3.1 ist. dazu ein Beispiel der befüllten “Debug View” zu sehen. Da im MDB die PU-Klasse das “IThread’-Int.erface implementiert, werden die PUs automatisch in der “Debug View” angezeigt..
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.1: Debug View - mit Instanzen der angegebenen Interfaces gefüllt.
Auch die von Eclipse Debug Framework gebotenen Möglichkeiten zur Implementierung von eigenen Breakpoints können gut wiederverwendet werden. So bietet das “Debug Core Plugin” einen Breakpoint.
[...]
1 IDE = Integrated Development Environment
2 Das Protokoll wird in Kapitel 4.1.2 vorgestellt.
1 Cross-Assembler: Tool zur Erzeugung eines Maschinenprogramms für eine bestimmte Zielarchitektur auf einem Rechner, dem eine andere Architektur zugrunde liegt.
2 Liste der 1000 größten US-amerikanischen Unternehmen, gemessen am Umsatz
3 Dass die Ausfallsicherheit dieser Maschinen eine ihrer großen Stärken ist, hat sich auch im Namen niedergeschlagen, denn das ”z” in ’’System z” steht für “zero downtime”.
4 IPL = Initial Program Load
1 Beim Interruptliandling wird ein Interruptanfruf behandelt. Der Interruptaufruf, der aus einem Anwendungsprogramm oder dem Betriebssystem gestartet wurde, führt zum Aufruf einer Interrutroutine. Eine Interruptroutine ist dabei eine spezielle Callback-Routine im Betriebssystem. Insbesondere ist hier zu bemerken, dass der interne Ablauf einer Interruptbehandlung vor dem Betriebssystem gekapselt ist. (vgl. [LCHELL04])
2 Aus Vertraiüiclikeitsgriinden sind zwei Instruktionen geschwärzt..
3 Bedingung für das Funktionieren dieses Verfahrens ist, dass die Registerinhalte noch korrekt ausgelesen werden können.
4 Instruction Unit
5 sExecution Unit
6 Angabe gilt für z990 Prozessor
7 'Für diese Arbeit ist der genaue Inhalt und das Format irrelevant.
8 AVP = Architecture Verification Program
9 Eclipse IDE (Basiskomponenten)
10 Standard-Oberfläclienelement, das vom Framework zur Verwendung in Anwendungsprogrammen bereitgestellt wird
11 nDetails zum Eclipse Debug Model können an folgenden Stellen nacligelesen werden: in [DAWR04, Seite 4] und [ECLHSY08].
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.