DE60010847T2 - Verfahren zur Fehlerbeseitigung in einem Thread-Programm - Google Patents

Verfahren zur Fehlerbeseitigung in einem Thread-Programm Download PDF

Info

Publication number
DE60010847T2
DE60010847T2 DE60010847T DE60010847T DE60010847T2 DE 60010847 T2 DE60010847 T2 DE 60010847T2 DE 60010847 T DE60010847 T DE 60010847T DE 60010847 T DE60010847 T DE 60010847T DE 60010847 T2 DE60010847 T2 DE 60010847T2
Authority
DE
Germany
Prior art keywords
thread
code
register
program
processor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE60010847T
Other languages
English (en)
Other versions
DE60010847D1 (de
Inventor
L. Winthrop SAVILLE
Kevin Ross
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics NV filed Critical Koninklijke Philips Electronics NV
Publication of DE60010847D1 publication Critical patent/DE60010847D1/de
Application granted granted Critical
Publication of DE60010847T2 publication Critical patent/DE60010847T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/28Error detection; Error correction; Monitoring by checking the correct order of processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging

Description

  • HINTERGRUND DER ERFINDUNG
  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf das Austesten von Computerprogrammen und, im Besonderen, auf die Fähigkeit, Mehrfachthreads auszutesten.
  • 2. Beschreibung des verwandten Standes der Technik
  • Es werden viele verschiedene Techniken angewandt, um Computerprogramme auszutesten. Eine übliche Technik ist, bei Auftreten eines bestimmten Vorfalls den Betrieb eines Programm-Threads (d.h. eine Befehlsfolge) zu stoppen und den Inhalt verschiedener Speicherstellen, z.B. Register, Adressen im RAM usw., zu prüfen. Eine sehr nützliche Einrichtung zum Stoppen eines Threads auf diese Weise ist der Unterbrechungspunkt. In „How debuggers work" von Rosenberg, J.B., Wiley Computer Publishing, New York, 1996, Seite 40–42, wird die Verwendung von Unterbrechungspunkten bei Softwareaustestung beschrieben. Unterbrechungspunkte werden in der Regel als spezieller Befehl implementiert, der eine Programmunterbrechung des Betriebssystems bewirkt, um dann ein spezielles Programm einsetzen zu können, welches als Diagnoseprogramm gespeichert ist. Unter Voraussetzung einer Adresse in dem ausführbaren Code, wo ein Unterbrechungspunkt zu setzen ist, kann das Diagnoseprogramm den aktuellen Befehl an dieser Stelle lesen und diesen zum Zwecke eines späteren Ersetzens speichern. Sodann speichert das Diagnoseprogramm den speziellen Unterbrechungspunktbefehl an dieser Stelle ein. Wenn nun die Ausführung des Diagnoseprogramms bei voller Prozessorgeschwindigkeit erfolgt, wenn der Prozessor einen dieser Unterbrechungspunktbefehle ausführt, wird eine spezielle Programmunterbrechung des Betriebssystems bewirkt, ohne dass das Diagnoseprogramm einen einzigen Befehl über den Unterbrechungspunkt hinaus ausführt. Zuweilen möchte das Diagnoseprogramm über diesen Unterbrechungspunkt hinaus gehen. In diesem Fall muss das Diagnoseprogramm zu dem zuvor gespeicherten Befehl zurückkehren und ihn ersetzen, diesen Befehl schrittweise abarbeiten und dann den Haltepunktbefehl ersetzen, bevor dem Diagnoseprogramm die Möglichkeit gegeben wird, bei voller Prozessorgeschwindigkeit erneut vorzugehen.
  • Unterbrechungspunkte, um die Ausführung eines momentan ablaufenden Threads zu stoppen, können so gesetzt werden, dass sie auf verschiedene Weisen auftreten. Beispiele umfassen Unterbrechungspunkte, welche auftreten, wenn auf einen spezifischen Speicherplatz zugegriffen wird. Ein typisches Beispiel zur Anwendung eines spezifischen Unterbrechungspunktbefehls ist in den 1A bis 1F dargestellt.
  • 1 zeigt eine Befehlsfolge in einem auszutestenden Thread. Jeder der Befehle enthält einen Op-Code, auf welche Parameter (z.B. Operanden, Adressen, Daten usw.) folgen, die dem jeweiligen Befehl zugeordnet sind. Typischerweise ist jeder Op-Code ein Byte lang. In diesem Beispiel enthält die Folge drei Befehle, d.h.:
    Befehl A mit Op-Code A, gefolgt von zwei zugeordneten Parametern A1 und A2;
    Befehl B mit Op-Code B, gefolgt von einem zugeordneten Parameter B1; sowie
    Befehl C mit Op-Code C, gefolgt von zwei zugeordneten Parametern C1 und C2.
  • Normalerweise wird jeder dieser Befehle unter Steuerung eines Programmschrittzählers in einem Prozessor gelesen und ausgeführt.
  • 1B zeigt, wie ein Unterbrechungspunkt in dem auszutestenden Thread zu setzen ist. Im Besonderen wird Op-Code B von dem Diagnoseprogramm durch einen Op-Code HALT ersetzt.
  • 1C stellt den Zeitpunkt dar, zu welchem der Prozessor Befehl A ausgeführt und den Wert PC in dem Programmschrittzähler bis zu der Adresse, unter welcher der Op-Code HALT gespeichert ist, inkrementiert hat. Zu diesem Zeitpunkt stoppt der Prozessor die Durchführung des Threads und meldet dem Diagnoseprogramm direkt oder indirekt, dass der Unterbrechungspunkt erreicht ist. Dieses kann auf verschiedene Weisen erfolgen, z.B. wenn der Prozessor bei dem Diagnoseprogramm eine Unterbrechung auslöst oder das Diagnoseprogramm den Zustand des Prozessors periodisch aufruft, um festzustellen, dass der Prozessor einen Op-Code HALT erreicht hat.
  • Wie in 1D dargestellt, reagiert das Diagnoseprogramm durch Abfragen des Wertes PC für den gestoppten Thread auf die Information des Op-Codes HALT, um festzustellen, welcher der (möglicherweise vielen) Unterbrechungspunkte erreicht wur de. Das Diagnoseprogramm schreibt dann den entsprechenden Op-Code (d.h. „Op-Code B", für den der Op-Code HALT in 1B eingesetzt wurde) in den Speicher 20 ein und weist den Prozessor an, den nächsten Befehl auszuführen. Bei Ausführen dieses Befehls liest der Prozessor den gerade eingespeicherten Op-Code B und inkrementiert den Programmschrittzähler, um die Adresse des zugehörigen Einzelbyteparameters B1 anzuzeigen.
  • Wie in 1E dargestellt, liest der Prozessor dann den zugehörigen Parameter und inkrementiert den Programmschrittzähler bis zu der Adresse von Op-Code C. Bei fertiger Ausführung von Befehl B stoppt der Prozessor, und das Diagnoseprogramm übernimmt wieder die Steuerung.
  • Wie in 1F dargestellt, setzt das Diagnoseprogramm nach Ausführung von Befehl B, jedoch vor Lesen des Op-Codes C, den Op-Code HALT wieder für Op-Code B in dem Programmstrom ein. Dieses ist erforderlich, um den Unterbrechungspunkt in dem Thread zu halten.
  • Aus dem in 1 dargestellten Beispiel kann ersehen werden, dass selbst eine Haltepunktaustestung eines einzelnen Threads ein komplizierter und zeitaufwendiger Vorgang sein kann.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Aufgabe der Erfindung ist, ein Verfahren zur Haltepunktaustestung vorzusehen, welches einfacher und weniger zeitaufwendig als bekannte Haltepunktaustestungstechniken ist.
  • Weiterhin ist es Aufgabe der Erfindung, ein Verfahren zur Austestung vorzusehen, welches in einer Mehrfachthread-Softwareumgebung das Austesten eines Threads ermöglicht, während andere Threads weiterhin durchgeführt werden können.
  • Gemäß einer Ausführungsform der Erfindung, wie in Anspruch 1 definiert, sieht ein Verfahren zur Austestung eines Programm-Threads mit einer, von einem Prozessor auszuführenden Befehlsfolge vor:
    Einsetzen eines Haltepunktindikators für einen ausgewählten Teil von zumindest einem der Befehle;
    Speicherung des ausgewählten Teils auf einem vorgegebenen Speicherplatz;
    Durchlaufen der Befehle, bis der Haltepunktindikator erreicht ist;
    Laden des ausgewählten Teils von dem Speicher in ein dediziertes Register;
    Ausführung von mindestens einer von mehreren vorgegebenen Austestungsoperationen.
  • Weitere Verbesserungen sind durch Unteransprüche 2–8 vorgesehen.
  • Es sei erwähnt, dass der Begriff „Speicher", wie hier verwendet, im Allgemeinen als der Art und Weise, in welcher er verwendet wird, entsprechend zu interpretieren ist und flüchtige sowie nicht flüchtige Bauelemente verschiedener Arten, einschließlich – ohne Einschränkung – RAMs, DRAMs, ROMs, Register und Kombinationen solcher Bauelemente aufweist. Ein „dedizierter" Speicher bedeutet, dass der Speicher einen oder mehrere spezifische Speicherstellen aufweist, welche dem Prozessor bekannt sind. Jedoch müssen diese Speicherstellen nicht festgelegt sein, sondern können unter der Steuerung des Prozessors verändert werden. Ebenso ist unter dem Begriff „Pointer" ein Wert zu verstehen, der eine Speicherstelle zuordnet. Darüber hinaus ist unter einem „Zugreifen" auf Daten das Abrufen von Daten aus einem Speicher oder das Einschreiben von Daten in einen solchen zu verstehen.
  • KURZBESCHREIBUNG DER ZEICHNUNG
  • Ausführungsbeispiele der Erfindung sind in der Zeichnung dargestellt und werden im Folgenden näher beschrieben. Es zeigen:
  • 1A bis 1F eine bekannte Haltepunkttechnik;
  • 2 ein Blockschaltbild eines exemplarischen Verarbeitungssystems, welches zur Erläuterung bevorzugter Ausführungsbeispiele der Erfindung von Nutzen ist;
  • 4A bis 3E eine Haltepunkttechnik gemäß einem Ausführungsbeispiel der Erfindung.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
  • Das Verarbeitungssystem von 2 weist einen Prozessor 10 und einen Speicher 20 auf. Der exemplarische Prozessor 10 ist ein Hardware-beschleunigtes Bauteil, welches Taktimpulse verwendet, um durch, von einem Programmschrittzähler erkannte Befehle zu steuern. Typischerweise enthält der Programmschrittzähler die Speicherstelle des als Nächstes zu lesenden und von dem Prozessor ausgeführten Befehls.
  • Der Prozessor weist einen Kontextregistersatz 12, einen Befehlsdecoder 14, ein Rechenwerk 16, ein SS-OP-CODE-Register 17, ein SS-TC-PTR-Register 18 sowie ein Register 19 mit einem Flag OP-CODE IST GÜLTIG auf. Der Speicher sieht in diesem ex emplarischen Ausführungsbeispiel eine Vielzahl Speicherstellen vor, um unter anderem eine große Anzahl Thread-Kontexte zu speichern.
  • Der Prozessor 10 und der Speicher 20 sind mit einem gemeinsamen Bus 30 verbunden, um miteinander und mit anderer Hardware, die an den Bus angeschlossen ist, zu kommunizieren. Der Bus weist jeweilige Leitungen auf, um Informationen, wie z.B. Adressen, Unterbrechungen, Daten, Lesestrobeimpulse, Schreibstrobeimpulse sowie Geräteansteuerstrobes zu übertragen. Vorzugsweise handelt es sich hier um einen Hochgeschwindigkeitsbus, welcher zumindest zum Teil mit dem Prozessor und dem Speicher auf einem gemeinsamen Siliciumsubstrat ausgebildet ist.
  • Der Kontextregistersatz 12 weist eine große Anzahl Register auf, um den von dem Prozessor 10 gerade durchgeführten Thread zu speichern. In dem bevorzugten Ausführungsbeispiel weist der Registersatz 12 auf:
    ein Programmschrittzählerregister 121 mit einem Wert PC, welchen der Prozessor kontinuierlich aktualisiert, um die Adresse des nächsten Befehls in dem Speicher 20, auf den zugegriffen wird, zuzuordnen;
    ein Register 122, um einen Pointer TC PTR, der eine Speicheradresse angibt, unter welcher der Kontext für den von dem Prozessor gerade durchgeführten Thread zu speichern ist, zu halten;
  • ein Register 123, um den von dem Prozessor gerade durchgeführten Thread betreffende STATUS-Informationen zu halten; sowie
    ein oder mehrere zusätzliche Register 125, um unter anderem zusätzliche Thread-Kontextinformationen und -daten zu halten, welche entweder aus dem Speicher 20 ausgelesen oder von dem Rechenwerk 16 erzeugt werden.
  • Der Befehlsdecoder 14 ist durch ein konventionelles Hardware-Bauelement, wie z.B. einen Steuerbaustein oder einen Mikroprogrammsteuerbaustein, zur Umwandlung der aus dem Speicher 20 ausgelesenen Befehle in Betriebscodes einer niedrigeren Stufe dargestellt.
  • Das SS-OP-CODE-Register 17, das SS-TC-PTR-Register 18 und das SS-OP-FLAG-Register 19 sind vorgesehen, um insbesondere Haltepunktaustestung betreffende Informationen zu halten. Im Besonderen hält Register 17 einen Op-Code von einem auszutestenden Thread (Debuggee-Thread), Register 18 einen, dem Debuggee-Thread zugeordneten Pointer SS TC PTR und Register 19 ein, dem Register 17 zugeordnetes Flag.
  • Bei Betrieb führt der Prozessor einen Thread (den laufenden Thread) auf einmal durch, jedoch kann auf verschiedene Weisen, z.B. durch eine interne Timer-Unterbrechung, durch eine externe Unterbrechung oder durch einen Befehl in dem laufenden Thread selbst, auf einen anderen Thread umgeschaltet werden. Wie vom Stand der Technik her bekannt, erfolgt dieses typischerweise durch Einschreiben des Kontextes des laufenden Threads (im Kontextregistersatz 12 gehalten) in die, durch den in Register 122 enthaltenen Pointer TC PTR angegebene Speicheradresse. Dann liest der Prozessor den jeweiligen Kontext für den als Nächstes durchzuführenden Thread in den Kontextregistersatz 12 ein.
  • Die 3A bis 3E zeigen allgemein ein Beispiel der Austestung eines Unterbrechungspunkts gemäß einem Ausführungsbeispiel der Erfindung. Um einen Vergleich zu ermöglichen, wird in diesem Beispiel die gleiche Befehlsfolge, die bei der in den 1A bis 1F dargestellten, bekannten Technik angewandt wird, eingesetzt.
  • Die 3A bis 3C sind mit den 1A bis 1C identisch. Das heißt, 3A zeigt die Befehlsfolge vor Einfügen eines Haltepunkt-Op-Codes; 3B zeigt, dass das Diagnoseprogramm den Haltepunkt-Op-Code HALT eingesetzt hat; und 3C zeigt den Zeitpunkt, zu welchem der Prozessor den Wert PC in dem Programmschrittzählerregister 121 bis zu der Adresse, unter welcher der Op-Code HALT gespeichert ist, inkrementiert hat. Zu diesem Zeitpunkt stoppt der Prozessor ebenfalls die Durchführung des Threads und meldet dem Diagnoseprogramm, dass der Unterbrechungspunkt erreicht worden ist.
  • Wie in 3D dargestellt, reagiert das Diagnoseprogramm durch Abfragen des Wertes PC für den gestoppten Thread auf die Information des Op-Codes HALT. Statt jedoch den Op-Code B (für den der Op-Code HALT eingesetzt wurde) über den Op-Code HALT zu schreiben, schreibt der Prozessor den Op-Code B in das SS-OP-CODE-Register 17 ein und setzt das Flag OP-CODE IST GÜLTIG, wobei der Op-Code HALT in dem Thread belassen wird. Der Prozessor inkrementiert dann den Programmschrittzähler, um die Adresse des betreffenden Einzelbyteparameters B1 anzuzeigen.
  • Wie in 3E dargestellt, liest der Prozessor den betreffenden Parameter B1, inkrementiert den Programmschrittzähler bis zu der Adresse von Op-Code C und führt den gerade gelesenen Befehl B aus.
  • Somit werden sämtliche Schritte, welche erforderlich gewesen wären, um wieder den Op-Code HALT für den Op-Code B einzusetzen, eliminiert. Dieses umfasst typischerweise das Anhalten des Prozessors bei beendeter Ausführung von Befehl B, das Überschreiben von Op-Code B mit dem Op-Code HALT sowie die Wiederaufnahme der Durchführung des unterbrochenen Threads oder eines anderen Threads.
  • Die spezifische Art und Weise, in welcher die Haltepunktaustestung durchgeführt wird, ist von den Optionen, mit denen das Diagnoseprogramm ausgestattet ist, und der Anzahl Threads, die der Prozessor durchführt, abhängig. Gemäß einem bevorzugten Ausführungsbeispiel der Erfindung ist das Diagnoseprogramm mit den folgenden Optionen, von denen, ungeachtet dessen, ob ein oder mehrere Threads durchgeführt werden, alle verfügbar sind, ausgestattet:
    Anhalten eines laufenden Threads;
    Einzelschrittausführung von einem Unterbrechungspunkt oder von einem anderen Punkt als einem Unterbrechungspunkt;
    Wiederaufnahme des Betriebs von einem Unterbrechungspunkt oder von einem anderen Punkt als einem Unterbrechungspunkt.
  • Um diese Optionen zu ermöglichen, sind Flags und Befehle zur Verwendung durch das Diagnoseprogramm und den Prozessor vorgesehen mit:
    einem Flag AUSFÜHRUNG, vorgesehen in den Informationen STATUS für jeden Thread, welches signalisiert, ob der jeweilige Thread ausgeführt oder gestoppt wird;
    einem Flag OP-CODE IST GÜLTIG, vorgesehen in Register 19, welches:
    bei Setzen signalisiert, dass ein, die Ausführung erwartender Op-Code in das SS-OP-CODE-Register 17 eingegeben wurde;
    bei Rücksetzen signalisiert, dass der nächste Befehl aus dem Programmstrom übernommen werden soll;
    einem Befehl EINZELSCHRITT, welcher bewirkt, dass der Prozessor den nächsten Befehl ausschließlich in einem unterbrochenen Thread durchführt;
    einem Befehl WIEDERAUFNAHME, welcher bewirkt, dass der Prozessor den Betrieb eines unterbrochenen Threads wieder aufnimmt.
  • Wird mehr als ein Thread durchgeführt, wird jeder auszutestende Thread bei Auftreten eines Op-Codes HALT unterbrochen, und das Flag AUSFÜHRUNG für diesen Thread wird zurückgesetzt. Der Prozessor fährt fort, sämtliche Threads nacheinander auszuführen, erkennt jedoch bei jedem Zugriff auf den Kontext den Rücksetzzustand des Flags AUSFÜHRUNG in diesem Kontext des Threads und unternimmt nichts, bis eine Unterbre chung stattfindet, wodurch bewirkt wird, dass der Prozessor der Reihe nach auf den nächsten Thread schaltet.
  • Das Diagnoseprogramm kann einen oder mehrere Threads austesten, wobei bei jedem einen oder mehrere Unterbrechungspunkte gesetzt werden. Um auf einen Op-Code HALT zu reagieren, muss das Diagnoseprogramm den Op-Code, für den der Op-Code HALT eingesetzt wurde, ermitteln können. Vorzugsweise erfolgt dieses dadurch, dass bewirkt wird, dass der Prozessor diesem die Threadkontextadresse für den Thread, welcher den Befehl HALT ausführte, meldet oder auf das Statusregister in dem Threadkontext für jeden Debuggee-Thread zugegriffen wird, um den Zustand der Flags AUSFÜHRUNG abzufragen. Es sei erwähnt, dass ein Rücksetzzustand, d.h. Unterbrechungszustand, bei mehr als einem Debuggee-Thread auf einmal bestehen kann.
  • Unterbrechen eines laufenden Threrads
  • Das Diagnoseprogramm kann wählen, ob es einen Thread, welcher gerade ausgeführt wird, unterbricht. Um dieses durchzuführen, weist das Diagnoseprogramm den Prozessor an, in das SS-TC-PTR-Register 18 einen Pointer einzugeben, welcher die, den Kontext für den laufenden Debuggee-Thread haltende Speicherstelle erkennt. Das Diagnoseprogramm gibt dann den Befehl HALT aus, wodurch bewirkt wird, dass der Prozessor:
    den Kontext eines gerade auszuführenden Threads in der Speicheradresse, auf welche von dem Pointer TC PTR, der sich augenblicklich in Register 122 befindet, hingewiesen wird, speichert;
    den Inhalt von Register 122 in Register 18 (um eine spätere Neuinstallierung des laufenden Threads zu ermöglichen) und den Inhalt von Register 18 (Pointer SS TC PTR) in Register 122 überträgt;
    den, unter der, von dem Pointer SS TC PTR (nun in Register 122) erkannten Speicheradresse gespeicherten Debuggee-Kontext in den Kontextregistersatz 12 einliest;
    das Flag BETRIEB zurücksetzt;
    den aktuellen Kontext für den gerade unterbrochenen Debuggee-Thread in den Speicher eingibt;
    den Inhalt von Register 18 in Register 122 überträgt, um eine Neuinstallierung des zuvor ausgeführten Threads vorzunehmen;
    den, unter der, von dem Pointer TC PTR in Register 122 erkannten Speicheradresse gespeicherten Thread-Kontext in den Kontextregistersatz 12 einliest.
  • Es sei erwähnt, dass der gespeicherte Kontext in dem Debuggee-Thread das Rücksetzen des Flags AUSFÜHRUNG vorsieht. Somit fährt der Prozessor fort, alle auszuführenden Threads zu durchlaufen, stellt jedoch jedes Mal bei Erreichen des Kontextes des Debuggee-Threads fest, dass das Flag AUSFÜHRUNG in den Informationen STATUS noch immer zurückgesetzt ist und führt den Debuggee-Thread nicht aus.
  • Einzelschrittausführung
  • Das Diagnoseprogramm kann wählen, ob es bei einem Thread, welcher unterbrochen ist, in Einzelschritten vorgeht. Zu diesem Zweck weist das Diagnoseprogramm den Prozessor an, das SS-TC-PTR-Register 18 mit einem Pointer zu laden, welcher die, den Kontext für den unterbrochenen Debuggee-Thread haltende Speicherstelle erkennt. Das Diagnoseprogramm fragt dann den Programmschrittzähler nach dem Debuggee-Thread ab, um festzustellen, ob dieser an einem Haltepunkt unterbrochen wurde. Falls dieser an einem Haltepunkt unterbrochen wurde, gibt er den Op-Code, für den der Op-Code HALT eingesetzt wurde (z.B. Op-Code B in 3D), in das SS-OP-CODE-Register 17 ein und setzt das Flag OP-CODE IST GÜLTIG. Wurde er nicht an einem Haltepunkt unterbrochen, ist das Flag OP-CODE IST GÜLTIG bereits zurückgesetzt worden.
  • Das Diagnoseprogramm gibt dann den Befehl EINZELSCHRITT aus, wodurch bewirkt wird, dass der Prozessor:
    den Kontext eines gerade auszuführenden Threads in der Speicheradresse, auf welche von dem Pointer TC PTR, der sich augenblicklich in Register 122 befindet, hingewiesen wird, speichert;
    den Inhalt von Register 122 in Register 18 (um eine spätere Neuinstallierung des laufenden Threads zu ermöglichen) und den Inhalt von Register 18 (Pointer SS TC PTR) in Register 122 überträgt;
    den, unter der, von dem Pointer SS TC PTR (nun in Register 122) erkannten Speicheradresse gespeicherten Debuggee-Kontext, der den Wert PC für den Unterbrechungspunkt, an welchem sich der Op-Code HALT befindet, aufweist, in den Kontextregistersatz 12 einliest;
    das Flag OP-CODE IST GÜLTIG prüft, um die Quelle des zu verwendenden Op-Codes, d.h. von Register 17, wenn das Flag gesetzt ist, oder von dem Programmstrom, wenn das Flag zurückgesetzt ist, zu ermitteln;
    das Flag OP-CODE IST GÜLTIG zurücksetzt, um darauf hinzuweisen, dass sich kein, die Ausführung erwartender Op-Code in Register 17 befindet;
    den Wert PC in Register 121 (z.B. bis zu der Adresse von Parameter B1 in 3D) inkrementiert;
    den (die) Parameter, sofern vorhanden, bei dem inkrementierten Wert PC (z.B. Parameter B1) liest;
    die beiden letzten Schritte wiederholt, was erforderlich ist, um (einen) zusätzliche(n) Parameter, welche den, aus Register 17 ausgelesenen Op-Code betreffen, zu lesen;
    den kompletten Befehl, welcher aus dem gerade gelesenen Op-Code und
    einem zugeordneten Parameter (zugeordneten Parametern) gebildet wird, ausführt und dann den Wert PC bis zu dem nächsten Op-Code (z.B. Op-Code C in 3E) inkrementiert;
    den aktuellen Kontext für den Debuggee-Thread, welcher gerade in Einzelschritten ausgeführt wurde, in den Speicher eingibt;
    den Inhalt von Register 18 in Register 122 überträgt, um eine Neuinstallierung des zuvor ausgeführten Threads vorzunehmen;
    den, unter der, von dem Pointer TC PTR in Register 122 erkannten Speicheradresse gespeicherten Thread-Kontext in den Kontextregistersatz 12 einliest.
  • Es sei erwähnt, dass der gespeicherte Kontext den Wert PC für den nächsten, in dem Debuggee-Thread auszuführenden Befehl und das Flag AUSFÜHRUNG, welches noch immer zurückgesetzt ist, aufweist. Somit fährt der Prozessor fort, sämtliche auszuführenden Threads durchzuführen, erkennt jedoch bei jedem Zugriff auf den Kontext des Debuggee-Threads, dass das Flag AUSFÜHRUNG in den Informationen STATUS noch immer zurückgesetzt ist und führt den Debuggee-Thread nicht durch.
  • Wiederaufnahme der Ausführung
  • Das Diagnoseprogramm kann wählen, ob es die Ausführung eines Threads, welcher unterbrochen wurde, wieder aufnimmt. Zu diesem Zweck weist das Diagnoseprogramm den Prozessor an, in das SS-TC-PTR-Register 18 einen Pointer einzugeben, welcher die, den Kontext für den unterbrochenen Debuggee-Thread haltende Speicherstelle erkennt.
  • Sodann fragt das Diagnoseprogramm den Programmschrittzähler nach dem Debuggee-Thread ab, um festzustellen, ob dieser an einem Haltepunkt unterbrochen wurde.
  • Falls dieser an einem Haltepunkt unterbrochen wurde, gibt er den Op-Code, für den der Op-Code HALT eingesetzt wurde (z.B. Op-Code B in 3D), in das SS-OP-CODE-Register 17 ein und setzt das Flag OP-CODE IST GÜLTIG.
  • Das Diagnoseprogramm gibt dann den Befehl WIEDERAUFNAHME aus, wodurch bewirkt wird, dass der Prozessor:
    den Kontext eines gerade auszuführenden Threads in der Speicheradresse, auf welche von dem Pointer TC PTR, der sich augenblicklich in Register 122 befindet, hingewiesen wird, speichert;
    den Inhalt von Register 122 in Register 18 (um eine spätere Neuinstallierung des laufenden Threads zu ermöglichen) und den Inhalt von Register 18 (Pointer SS TC PTR) in Register 122 überträgt;
    den, unter der, von dem Pointer SS TC PTR (nun in Register 122) erkannten Speicheradresse gespeicherten Debuggee-Kontext, welcher den Wert PC für den Unterbrechungspunkt, an welchem sich der Op-Code HALT befindet, aufweist, in den Kontextregistersatz 12 einliest;
    das Flag OP-CODE IST GÜLTIG prüft, um die Quelle des zu verwendenden Op-Codes, d.h. von Register 17, wenn das Flag gesetzt wird, oder von dem Programmstrom, wenn das Flag zurückgesetzt ist, zu ermitteln;
    das Flag OP-CODE IST GÜLTIG zurücksetzt, um darauf hinzuweisen, dass sich kein, die Ausführung erwartender Op-Code in Register 17 befindet;
    den Wert PC in Register 121 (z.B. bis zu der Adresse von Parameter B1 in 3D) inkrementiert;
    den (die) Parameter bei dem inkrementierten Wert PC (z.B. Parameter B1) liest;
    die beiden letzten Schritte wiederholt, was erforderlich ist, um (einen) zusätzliche(n) Parameter, welche den, aus Register 17 ausgelesenen Op-Code betreffen, zu lesen;
    das Flag AUSFÜHRUNG in den, in Register 123 enthaltenen Informationen STATUS setzt;
    den kompletten Befehl, welcher aus dem gerade gelesenen Op-Code und einem zugeordneten Parameter (zugeordneten Parametern) gebildet wird, ausführt und dann
    den Wert PC bis zu dem nächsten Op-Code (z.B. Op-Code C in 3E) inkrementiert;
    den aktuellen Kontext für den Debuggee-Thread in den Speicher eingibt;
    den Inhalt von Register 18 in Register 122 überträgt, um eine Neuinstallierung des zuvor ausgeführten Threads vorzunehmen;
    den, unter der, von dem Pointer TC PTR in Register 122 erkannten Speicheradresse gespeicherten Thread-Kontext in den Kontextregistersatz 12 einliest.
  • Alternativ, falls keine Unterbrechung an einem Haltepunkt erfolgte, wurde das Flag OP-CODE IST GÜLTIG bereits zurückgesetzt. Das Diagnoseprogramm gibt dann den Befehl WIEDERAUFNAHME aus, wodurch bewirkt wird, dass der Prozessor:
    den Kontext eines gerade auszuführenden Threads in der Speicheradresse, auf welche von dem Pointer TC PTR, der sich augenblicklich in Register 122 befindet, hingewiesen wird, speichert;
    den Inhalt von Register 122 in Register 18 (um eine spätere Neuinstallierung des laufenden Threads zu ermöglichen) und den Inhalt von Register 18 (Pointer SS TC PTR) in Register 122 überträgt;
    den, unter der, von dem Pointer SS TC PTR (nun in Register 122) erkannten Speicheradresse gespeicherten Debuggee-Kontext, welcher den Wert PC für den Unterbrechungspunkt, an welchem sich der Op-Code HALT befindet, aufweist, in den Kontextregistersatz 12 einliest;
    das Flag AUSFÜHRUNG in den, in Register 123 enthaltenen Informationen STATUS setzt;
    den aktuellen Kontext für den Debuggee-Thread in den Speicher eingibt;
    den Inhalt von Register 18 in Register 122 überträgt, um eine Neuinstallierung des zuvor ausgeführten Threads vorzunehmen;
    den, unter der, von dem Pointer TC PTR in Register 122 erkannten Speicheradresse gespeicherten Thread-Kontext in den Kontextregistersatz 12 einliest.
  • Es sei erwähnt, dass der gespeicherte Kontext den Wert PC für den nächsten, in dem Debuggee-Thread auszuführenden Befehl und das Flag AUSFÜHRUNG (welches nun gesetzt ist) aufweist. Somit fährt der Prozessor fort, sämtliche auszuführenden Threads durchzuführen, wobei er bei jedem Zugriff auf den Kontext des Debuggee-Threads erkennt, dass das Flag AUSFÜHRUNG in den Informationen STATUS gesetzt ist und den Debuggee-Thread durchführt.

Claims (8)

  1. Verfahren zur Austestung eines Programm-Threads mit einer, von einem Prozessor auszuführenden Befehlsfolge, welches vorsieht: a) Einsetzen eines Haltepunktindikators (HALT) für einen ausgewählten Teil (Op-Code B) von zumindest einem der Befehle; b) Speicherung des ausgewählten Teils (Op-Code B) in einem Speicher; c) Durchlaufen der Befehle, bis der Haltepunktindikator (HALT) erreicht ist; d) Laden des ausgewählten Teils (Op-Code B) von dem Speicher in ein dediziertes Register (17); e) Ausführung von mindestens einer von mehreren vorgegebenen Austestungsoperationen.
  2. Verfahren nach Anspruch 1, wobei der ausgewählte Teil in dem dedizierten Register (17) gespeichert und von diesem abgerufen wird.
  3. Verfahren nach Anspruch 1, wobei der ausgewählte Teil einen Op-Code aufweist.
  4. Verfahren nach Anspruch 1, wobei der ausgewählte Teil einen Op-Code HALT aufweist, um die Durchführung des Threads zu unterbrechen.
  5. Verfahren nach Anspruch 1, wonach bei den vorgegebenen Austestungsoperationen a) die Durchführung des Programm-Threads an dem Haltepunkt unterbrochen wird; b) bei einem unterbrochenen Thread in Einzelschritten vorgegangen wird; c) die Durchführung eines unterbrochenen Threads wieder aufgenommen wird.
  6. Verfahren nach Anspruch 1, wobei ein Flag vorgesehen ist, um anzugeben, ob der ausgewählte Teil in den dedizierten Speicher eingelesen wurde und auf die Anwendung wartet.
  7. Verfahren zur Austestung eines Programm-Threads nach Anspruch 1, wobei der Programm-Thread einer von mehreren Programm-Threads ist, welche von einem Prozessor ausgeführt werden können, und wobei nach dem Verfahren weiterhin – ein Ausführungsstatusindikator in einem jeweiligen Kontext für jeden der Threads vorgesehen ist; – jeder Thread, bei welchem sich der Statusindikator in einem ersten Zustand befindet, ausgeführt wird; – jeder Thread, bei welchem sich der Statusindikator in einem zweiten Zustand befindet, nicht ausgeführt wird.
  8. Verfahren nach Anspruch 7, wobei ein Diagnoseprogramm den Ausführungsstatusindikator einsetzt, um einen Thread zur Austestung auszuwählen, während mindestens ein weiterer Thread weiterhin ausgeführt werden kann.
DE60010847T 1999-09-07 2000-08-21 Verfahren zur Fehlerbeseitigung in einem Thread-Programm Expired - Fee Related DE60010847T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US39085399A 1999-09-07 1999-09-07
US390853 1999-09-07
PCT/EP2000/008183 WO2001018651A1 (en) 1999-09-07 2000-08-21 Thread-oriented debugging

Publications (2)

Publication Number Publication Date
DE60010847D1 DE60010847D1 (de) 2004-06-24
DE60010847T2 true DE60010847T2 (de) 2005-06-16

Family

ID=23544212

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60010847T Expired - Fee Related DE60010847T2 (de) 1999-09-07 2000-08-21 Verfahren zur Fehlerbeseitigung in einem Thread-Programm

Country Status (7)

Country Link
EP (1) EP1125199B1 (de)
JP (1) JP2003508864A (de)
KR (1) KR20010085997A (de)
CN (1) CN1148656C (de)
DE (1) DE60010847T2 (de)
TW (1) TW518460B (de)
WO (1) WO2001018651A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100952762B1 (ko) * 2003-02-27 2010-04-14 엘지전자 주식회사 디지털 시그널 프로세서의 실시간 디버깅 방법
GB0420442D0 (en) * 2004-09-14 2004-10-20 Ignios Ltd Debug in a multicore architecture
CN100389565C (zh) * 2005-03-08 2008-05-21 华为技术有限公司 一种实现报警判决的方法
US8341604B2 (en) * 2006-11-15 2012-12-25 Qualcomm Incorporated Embedded trace macrocell for enhanced digital signal processor debugging operations
US7657791B2 (en) 2006-11-15 2010-02-02 Qualcomm Incorporated Method and system for a digital signal processor debugging during power transitions
US8370806B2 (en) * 2006-11-15 2013-02-05 Qualcomm Incorporated Non-intrusive, thread-selective, debugging method and system for a multi-thread digital signal processor
US8484516B2 (en) 2007-04-11 2013-07-09 Qualcomm Incorporated Inter-thread trace alignment method and system for a multi-threaded processor
CN101295279B (zh) * 2007-04-29 2012-05-09 国际商业机器公司 多线程环境下的调试程序的方法和系统
GB2489000B (en) * 2011-03-14 2019-09-11 Advanced Risc Mach Ltd Diagnosing code using single step execution
CN107818043A (zh) * 2016-09-13 2018-03-20 东华软件股份公司 用于程序调试的方法和装置
CN110489294B (zh) * 2019-08-23 2023-12-19 上海光电医用电子仪器有限公司 一种基于日志实时单步调试方法和装置

Also Published As

Publication number Publication date
DE60010847D1 (de) 2004-06-24
JP2003508864A (ja) 2003-03-04
TW518460B (en) 2003-01-21
CN1148656C (zh) 2004-05-05
EP1125199A1 (de) 2001-08-22
KR20010085997A (ko) 2001-09-07
EP1125199B1 (de) 2004-05-19
CN1335962A (zh) 2002-02-13
WO2001018651A1 (en) 2001-03-15

Similar Documents

Publication Publication Date Title
DE4011745C2 (de)
DE69720821T2 (de) Fehlersuchsystem für Programme mit einer graphischen Benutzerschnittstelle
DE102004004796B4 (de) Vorrichtung zur Datenübertragung zwischen Speichern
DE102008012337A1 (de) Programmcode-Trace-Signatur
CH654943A5 (de) Pruefeinrichtung fuer mikroprogramme.
DE4313594A1 (de) Mikroprozessor
DE60010847T2 (de) Verfahren zur Fehlerbeseitigung in einem Thread-Programm
EP1019819B1 (de) Programmgesteuerte einheit und verfahren zum debuggen derselben
DE1275800B (de) Steuerwerk fuer datenverarbeitende Maschinen
EP0500973A1 (de) Initialisierungsroutine im EEPROM
DE2101949A1 (de) Verfahren zum Schutz von Datengruppen in einer Multiprocessing-Datenverarbeitungsanlage
EP3080668B1 (de) Verfahren zur beeinflussung eines steuerprogramms eines steuergeräts
EP0450116B1 (de) Automatisierungsgerät mit Test in einzelnen Schritten
DE112011100168T5 (de) Erfassen von Diagnosedaten in einer Datenverarbeitungsumgebung
DE3323824A1 (de) Speicherprogrammierbare steuerung
DE3700800C2 (de) Einrichtung zur Erzeugung eines Unterbrechungspunktes in einem Mikroprozessor
DE2723706A1 (de) Einrichtung zum adressenvergleich
DE69626282T2 (de) Programmierbare vorrichtung und verfahren zum befehlsauffang
WO2000043885A1 (de) Verfahren zum tracen von daten
DE102007015507B4 (de) Prozessor mit einem ersten und einem zweiten Betriebsmodus und Verfahren zu seinem Betrieb
DE2622140C3 (de) Einrichtung zur Steuerung manueller Operationen
DE19903302B4 (de) Verfahren und Vorrichtung zur Überprüfung der Funktion eines Rechners
EP1516245B1 (de) Vorrichtung und verfahren zum verarbeiten einer sequenz von sprungbefehlen
DE10116864A1 (de) Verfahren zum Emulieren einer programmgesteuerten Einheit
DE3643560A1 (de) Flexible korrektur von firmware

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee