Browse Prior Art Database

Debugger mit Patch-Möglichkeit für laufzeitkritische Software

IP.com Disclosure Number: IPCOM000018318D
Original Publication Date: 2002-Apr-01
Included in the Prior Art Database: 2003-Jul-23
Document File: 1 page(s) / 147K

Publishing Venue

Siemens

Related People

Dr. Georg Czedik-Eysenberg: AUTHOR [+4]

Abstract

Das Debuggen bzw. Testen von Software ist immer mit einem Eingriff (Verzögerung) in den Software- ablauf verbunden, was einen Test von laufzeitkriti- scher Software nahezu unmöglich machen kann. Im Wesentlichen sind drei Kategorien von Testaktionen notwendig: [g183] [g183] Interaktives Debuggen auf Source Level Ebene

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Information / Kommunikation

Debugger mit Patch-Möglichkeitfür laufzeitkritische Software

Idee: Dr. Georg Czedik-Eysenberg, A-Wien;

Walter Fasching, A-Wien;Peter Mittermaier, München;Johann Schefer, A-Wien

Das Debuggen bzw. Testen von Software ist immermit einem Eingriff (Verzögerung) in den Software-ablauf verbunden, was einen Test von laufzeitkriti-scher Software nahezu unmöglich machen kann. ImWesentlichen sind drei Kategorien von Testaktionennotwendig:

•� � Interaktives Debuggen auf Source Level Ebene(Setzen� von� Haltepunkten� und Anzeigen/ Än-dern von symbolischen Ausdrücken am Halte-punkt) – verbunden mit Stopp des zu testendenProgrammes� � � � völlige Veränderung des Lauf-zeitverhaltens

•� � Tracen von symbolischen Ausdrücken an vorde-finierten Punkten mit möglichst zeitgleicher An-zeige� � � � geringe Laufzeitverfälschung

•� � Durchführung von Softwarekorrekturen (Pat-chen) auf Programmiersprachenebene (ohneNeuproduktion der zu testenden Software) mitHilfe des Testtools mit möglichst geringer Lauf-zeitverfälschung

Bisher gibt es kein einheitliches Testtool, das dieseTestaktionen in beliebiger Kombination und Reihen-folge zur Verfügung� stellt,� da� die� verschiedenenTestaktionen unterschiedliche Architekturen desTesttools erfordern.

Es wird ein Debugger vorgeschlagen, der aus zweiKomponenten, einem „PC-Teil“� und einem „APS-Teil“� besteht. Der PC-Teil läuft z.B. auf einem Win-dows-PC als Prozess ab. Er enthält die graphischeBenutzeroberfläche,� die� Kommandoanalyse,� einen„Quick-Intermediate-Language(QIL)-Generator“ unddie Ausgabedatenaufbereitung. Der Anlagen-Programm-System(APS)-Teil wird zu der zu testen-den� (ggf.� an� einem� anderen� Rechner,� z.B. einemTelefon-Vermittlungs-System ablaufenden) Softwarehinzugebunden und enthält das Breakpoint-Management, das Interrupt-Handling und einen„Quick Executer“.

Die Debugger-Kommandos werden vom PC-Teil inQIL umgewandelt, über eine Schnittstelle (z.B. V24oder TCP/IP)� zum� APS-Teil� übertragen� und� dortvom Quick-Executer entweder sofort ausgeführt oderim� Zusammenhang� mit� einem� (z.B.� Trace- oderPa...