System z Millicode Debugger

Entwicklung eines System z Millicode Debugger Plug-ins für Eclipse basierend auf einer Anbindung an den existierenden Millicode Emulator

Bachelorarbeit , 2009 , 112 Seiten , Note: 1,0

Informatik - Software

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 Develop­ments
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 Bachelor­arbeit, 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 Er­reichen der genannten Ziele bei und sind unter anderem auch deshalb von zunehmender Wichtigkeit. In den meisten Umgebungen stehen derartige Werkzeuge bereits zur Ver­fügung. Dies gilt insbesondere für die meisten Hochsprachen, zu denen meist grafische Debugger existieren, die oft darüber hinaus in einer IDE¹ 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 grafi­scher 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. Ein­gebracht werden die Eclipse Erweiterungen über sogenannte Eclipse Plug-ins. Ein weite­rer 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 Erweiterun­gen unterstützt der Millicode Emulator nun auch das interaktive Debuggen des Millico­des. Dazu stellt der Emulator eine zusätzliche Schnittstelle bereit, durch die er über das “GDB Remote Serial Protocol”² angesprochen werden kann. Der dritte Teil der Arbeit be­steht 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 verwen­deten Technologien eingegangen. Hierzu wird die System z Serverfamilie im Kapitel 1 kurz vorgestellt. Dabei wird besonderes Augenmerk auf die System z Firmware gelegt. Die Auf­gaben 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 Funktio­nalitä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 Featu­res für den Millicode Debugger entworfene Entwicklungsprozess vorgestellt. Dieser bedient sich verschiedener Methoden aus dem “Agile Development”. Anschließend folgt eine exem­plarische Beschreibung der Implementierung des MDB anhand von ausgewählten Funktio­nalitäten.

Kapitel 1

Einleitung

1.1 Umfeld der Arbeit

Diese Bachelorarbeit wurde bei der Abteilung “Processor Firmware Development” im Ent­wicklungslabor der Firma IBM Deutschland Research and Development in Böblingen ange­fertigt. 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 Bereit­stellung einer vollständigen IDE zur Entwicklung des System z Millicodes auf den Entwick­lerworkstations. 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-Assembler¹ 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 ei­ner 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 Entwick­lungsumgebung 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 Informa­tionen 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 Benutzer­oberflä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 For­tune 1000 gelistet sind², haben in ihren Rechenzentren eine Mainframeumgebung installiert. Aber nicht nur am Anwen­derkreis kann man die Bedeutung des Mainframes festma­chen. Deutlich wird dieser auch anhand des Faktums, dass ein wesentlicher Prozentsatz der im Internet verfügbaren Da­ten 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 bei­spielsweise:

- Hochverfügbarkeit (Ausfallsicherheit)³
- 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 Konso­lidierung 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 Hard­ware 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 Firm­ware abgebildet (LPAR Hypervisor, i390 code und Millicode). Die Firmware stellt das Zwischenstück zwischen der Prozessor Hardware und der Software bzw. dem Betriebssys­tem der System z dar. Sie wird beim Bootvorgang (im Mainframeterminus: “IPL”⁴ ) 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 des­sen 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) be­legen. 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 imple­mentiert sind. Zwar sind viele Instruktionen auf dem z Prozessor direkt in Hardware ’’ge­gossen”, 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 Handlers¹ 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 gefun­den 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.² 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 Maschinenge­neration der System z Serverfamilie kann bis zu 80 CPs (Central Processor Kerne) beher­bergen, 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)³ 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 Milli­code 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 da­hin 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 Haupt­speichers 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” ⁴ des Prozessors holt die Millicode Instruktion aus dem Cache und dekodiert diese. Anschließend werden die Adressen der Operanden berech­net, diese aus dem Cache bzw. Hauptspeicher geholt und die Instruktion in der “E-unit”⁵ ausgeführt, (nach [LCHELL04])

Jedoch können einige Instruktionen und Register nur verwendet werden, wenn sich der Pro­zessor im Millicode-Modus befindet (nach [BBEHKST02]). Beispielsweise arbeiten Instruk­tionen, welche normalerweise die 16 allgemein sichtbaren “Program general registers” ver­wenden, 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 Mil­licode Assembler ist eine Form der z/Architecture Assembler-Sprache. Jedoch können im Gegensatz zum “High Level Assembler” (HLASM), der zur Implementierung von Betriebs­systemen und Anwendungsprogrammen genutzt werden kann, nur die architekturierten Befehle, die direkt von der Hardware ausgeführt werden, in Millicode-Routinen verwen­det 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 Instruk­tionen⁶, 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 komplet­ten 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 Millico­de zu einer ganz speziellen Anwendungsdomäne und sind der Grund, warum keine Stan­dardprodukte, die das Debuggen von System z Assembler Programmen erlauben, in der Firmware-Entwicklung eingesetzt werden können. Denn wäre der Millicode im Anwen­dungsmodus ausführbar, wäre ein Debugging mit Hilfe eines verfügbaren HLASM Compi­lers 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 Op­Code 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 einge­setzt, 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 Hard­ware 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 le­diglich die Informationen zur Verfügung stehen, die der MCE während des Testlaufes pro­tokolliert 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 Daten­menge (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.⁷

Das Testcase-File, das der MCE als Input verarbeitet, ist eine Datei im IBM-eigenen AVP-Format⁸. Es enthält einen oder mehrere komplette(n) Testcase(s) mit je einem Ma­schinenprogramm, 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 Arbeitsspeicherin­halte 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 ei­nem Round-Robin-Verfahren auf jeder PU nacheinander eine Instruktion ausgeführt (vgl. [BBEHKST02]).

Beim Ausführen wird zwischen in Millicode implementierten und in Hardware implemen­tierten 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 Einsprung­adresse 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 Workbench⁹ 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 Eclip­se 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 ver­schiedene 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 Werkzeugun­terstü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 Ab­hä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 Anga­be, 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 ge­nauer 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 Erweiterun­gen 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 da­zu, Eclipse mit selbst definierten Breakpoint-Klassen zu erweitern. Im inneren Tag break­point 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, mar­kerType, 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 kompilier­ten .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 unter­schiedlicher Plug-in Versionen, die in einer Eclipse Instanz installiert sind.

Ein sehr komfortables Feature von Eclipse ist das Installieren und Updaten von Plug­ins ü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 Hinzu­fü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 Frame­work. Mit dessen Hilfe können Standardwidgets¹⁰ 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 bie­tet 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 Mo­dels, die im MDB verwendet werden.¹¹ 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 verwende­te 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 Gege­benheiten, die Eclipse bietet, zusammenpassen. Der zweite Teil beschäftigt sich mit der Beschreibung des Bedienkonzepts zum Millicode Debugger. Das umfasst sowohl die Erfas­sung 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 Zusammen­hang 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 Aus­fü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ög­lichen. 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 wer­den. 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 Editor­fenster 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 Re­gisterinhalten 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 verwen­den. 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 Entwickler­rechnern verwendet wird, sind vom MDB beide Plattformen zu unterstützen. Dieser Anforderung kommt entgegen, dass der in der Programmiersprache “C” implemen­tierte 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 einzusetzen­de 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 Debug­ging 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 Erweiterungs­mö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. Eben­falls 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 Be­triebssystemprozessen 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 Plug­in” einen Breakpoint.

[...]

---

¹ IDE = Integrated Development Environment

² Das Protokoll wird in Kapitel 4.1.2 vorgestellt.

¹ Cross-Assembler: Tool zur Erzeugung eines Maschinenprogramms für eine bestimmte Zielarchitektur auf einem Rechner, dem eine andere Architektur zugrunde liegt.

² Liste der 1000 größten US-amerikanischen Unternehmen, gemessen am Umsatz

³ 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”.

⁴ IPL = Initial Program Load

¹ Beim Interruptliandling wird ein Interruptanfruf behandelt. Der Interruptaufruf, der aus einem An­wendungsprogramm 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])

² Aus Vertraiüiclikeitsgriinden sind zwei Instruktionen geschwärzt..

³ Bedingung für das Funktionieren dieses Verfahrens ist, dass die Registerinhalte noch korrekt ausgelesen werden können.

⁴ Instruction Unit

⁵ sExecution Unit

⁶ Angabe gilt für z990 Prozessor

⁷ 'Für diese Arbeit ist der genaue Inhalt und das Format irrelevant.

⁸ AVP = Architecture Verification Program

⁹ Eclipse IDE (Basiskomponenten)

¹⁰ Standard-Oberfläclienelement, das vom Framework zur Verwendung in Anwendungsprogrammen be­reitgestellt wird

¹¹ nDetails zum Eclipse Debug Model können an folgenden Stellen nacligelesen werden: in [DAWR04, Seite 4] und [ECLHSY08].

• Hochschule: Georg-Simon-Ohm-Hochschule Nürnberg
• Note: 1,0
• Autor: Michael Hausmann (Autor:in)
• Erscheinungsjahr: 2009
• Seiten: 112
• Katalognummer: V174485
• ISBN (eBook): 9783640970995
• ISBN (Buch): 9783640972371
• Sprache: Deutsch
• Schlagworte: Eclipse Plugin, Eclipse Plug-In, Eclipse, Debug Framework, System z Millicode, GDB Remote Serial Protocol