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
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
Zielsetzung & Themen
Das primäre Ziel dieser Bachelorarbeit ist die Entwicklung eines grafischen Debuggers für den IBM System z Millicode, welcher nahtlos in die Entwicklungsumgebung Eclipse integriert wird. Hierbei liegt der Fokus auf der Schaffung einer interaktiven Schnittstelle, die es Entwicklern ermöglicht, den bisher im Batch-Betrieb arbeitenden Millicode Emulator (MCE) effizienter zu analysieren, Fehler zu lokalisieren und den Programmlauf gezielt zu steuern.
- Integration einer interaktiven Benutzeroberfläche in Eclipse zur Millicode-Fehlersuche.
- Erweiterung des bestehenden MCE um eine Kommunikationsschnittstelle basierend auf dem GDB Remote Serial Protocol.
- Implementierung von Debugging-Funktionen wie Single Step, Breakpoints und Register-Manipulation.
- Entwurf einer modularen Drei-Schichten-Architektur zur Entkopplung von GUI, Connector und Emulator.
- Anwendung agiler Entwicklungsmethoden zur iterativen Verbesserung und Priorisierung der Features.
Auszug aus dem Buch
4.1.2 Kommunikationsschnittstelle und Kommunikationsprotokoll
In diesem Abschnitt werden die Kommunikationsschnittstelle und das Kommunikationsprotokoll, die im Connector durch den MCE bereitgestellt werden, erläutert.
Um in Zukunft eine Flexibilität in Bezug auf den Ausführungsort der mit dem Millicode Debugger verbundenen MCE Instanz genießen zu können, wurde eine TCP/IP Socket-Verbindung als Basis für die Kommunikation zwischen MCE und Connector gewählt. Diese Lösung wurde einer maschineninternen Kommunikationsmethode, wie z.B. ein gegenseitiger Aufruf von Connector und MCE Binary über JNI vorgezogen. Dadurch ist die im Rahmen dieser Bachelorarbeit entwickelte Debugger-Lösung auch sehr leicht zu einer verteilten Anwendung modifizierbar. Damit die Designgrundlage gelegt, um in Zukunft auch von einer Entwickler-Workstation aus auf MCE Instanzen auf einem Server-rechner debuggen zu können, mehrere PUs in jeweils eigenen Eclipse Instanzen unabhängig debuggen zu können oder von einem entfernten Rechner aus den Zustand einer Emulation auf der Workstation eines Kollegen zu betrachten.
Die Kommunikationsbehandlung, also das Senden und Empfangen von Nachrichten über den Socket, wird im bestehenden MCE-Thread abgearbeitet, womit der MCE “single threaded” bleibt. Das trägt dazu bei, die Komplexität des MCEs nicht unnötig zu steigern und damit die Wartbarkeit des MCEs nicht negativ zu beeinflussen.
Nachdem der Kommunikationskanal nun als TCP/IP Socket-Verbindung festgelegt wurde, wird im Folgenden eingegangen wie das Kommunikationsprotokoll (d.h. das Format und die Semantik der Nachrichten) zwischen Connector und erweiterten MCE definiert ist. Dazu wurde eine bestehende Technologie, das GDB Remote Serial Protocol, wiederverwendet.
Das GDB Remote Serial Protocol ist ein bestehendes Protokoll, das dazu verwendet wird, den GNU Debugger (GDB) zu befähigen auch Programme auf entfernten Rechner debuggen zu können. Dazu kommuniziert der GNU Debugger mit einem GDB Server (GDBS) auf dem entfernten Rechner, der die Verbindung zwischen GDB und dem debuggenden Programm darstellt. Dieses Protokoll eignet sich auch hervorragend für den Einsatz im Kontext der Millicode Debuggers, da: die einzelnen Protokollbestandteile (Nachrichtentypen) für die diversen Connector zur Verfügung stellenden Informationen nicht neu definiert werden müssen, sondern eine Wiederverwendung von “Best Practices” stattfindet.
Zusammenfassung der Kapitel
1 Einleitung: Beschreibt das Umfeld der Arbeit bei der IBM, die Zielsetzung zur Entwicklung einer IDE-gestützten Umgebung für den Millicode und die aktuelle Problematik des Batch-Betriebs des Emulators.
2 Grundlagen: Erläutert die technischen Aspekte des System z Millicodes, des Millicode Emulators (MCE) sowie die Funktionsweise der Eclipse-Plattform als Basis für die Plugin-Entwicklung.
3 Anforderungen und Fachkonzept: Definiert die funktionalen Anforderungen an den Debugger und beschreibt das Bedienungskonzept innerhalb der Eclipse-Oberfläche sowie die Status-View.
4 Systemarchitektur: Detailliert die modulare Drei-Schichten-Architektur des Debuggers und die notwendigen Erweiterungen am MCE sowie die Wahl der GDB-basierten Kommunikationsschicht.
5 Vorgehensmodell: Beschreibt den agilen Entwicklungsprozess, der aus Methoden von SCRUM und Extreme Programming abgeleitet wurde, um auf Stakeholder-Feedback reagieren zu können.
6 Konzepte und Implementierungsdetails ausgewählter Features des Millicode Debuggers: Bietet tiefgehende Einblicke in die Implementierung des Launchers, des Connector-Designs, der Breakpoint-Verwaltung und der Register-Zugriffe.
7 Ausblick und Reflexion: Fasst die Ergebnisse der Arbeit zusammen, bewertet das erreichte Ziel einer einsatzfähigen Debugger-Lösung und gibt einen Ausblick auf zukünftige Erweiterungsmöglichkeiten.
Schlüsselwörter
System z, Millicode, Debugger, Eclipse, MCE, GDB Remote Serial Protocol, Plugin-Entwicklung, Softwarearchitektur, Agile Entwicklung, Breakpoints, Registerverwaltung, Connector, Emulation, Firmware, Java
Häufig gestellte Fragen
Worum geht es in der Arbeit grundsätzlich?
Es geht um die Entwicklung eines grafischen Debuggers für den IBM System z Millicode, der direkt in die Eclipse-Entwicklungsumgebung integriert wird.
Was sind die zentralen Themenfelder?
Die Themen umfassen System z Firmware, Eclipse-Plugin-Programmierung, Emulator-Erweiterung sowie die Implementierung einer Kommunikationsschicht zwischen Java-UI und C-basiertem Emulator.
Was ist das primäre Ziel der Arbeit?
Das Ziel ist der Übergang von einer batch-basierten Fehlersuche hin zu einer interaktiven Debugging-Lösung, um die Entwicklungseffizienz bei der Millicode-Wartung zu steigern.
Welche wissenschaftliche Methode wird verwendet?
Es wird eine modulare Software-Architektur entworfen und nach einem agilen Vorgehensmodell (angelehnt an SCRUM) implementiert, um Stakeholder-Feedback kontinuierlich zu integrieren.
Was wird im Hauptteil behandelt?
Der Hauptteil gliedert sich in die Anforderungsanalyse, das System-Fachkonzept, die Architekturplanung (Drei-Schichten-Modell) sowie die spezifische Implementierung von Features wie Launch-Dialogen, Breakpoints und Registerzugriffen.
Welche Schlüsselwörter charakterisieren die Arbeit?
Millicode, Eclipse, Debugger, System z, MCE, Connector, GDB-Protokoll und agile Entwicklung sind die zentralen Begriffe.
Warum wurde das GDB Remote Serial Protocol gewählt?
Es bietet ein standardisiertes, erprobtes Format für die Kommunikation zwischen Debugger-Client und Server, was die Flexibilität erhöht und die Wartbarkeit des MCEs durch Wiederverwendung bewährter Konzepte sichert.
Welchen Vorteil bietet die modulare Architektur?
Sie ermöglicht eine klare Trennung zwischen Benutzeroberfläche und Connector, wodurch der Debugger wartungsfreundlicher wird und zukünftige Änderungen am Emulator oder der IDE mit geringerem Aufwand möglich sind.
- Citation du texte
- Michael Hausmann (Auteur), 2009, System z Millicode Debugger, Munich, GRIN Verlag, https://www.grin.com/document/174485
