WO2014166526A1 - Mehrkern-prozessorsystem mit fehleranalysefunktion - Google Patents
Mehrkern-prozessorsystem mit fehleranalysefunktion Download PDFInfo
- Publication number
- WO2014166526A1 WO2014166526A1 PCT/EP2013/057382 EP2013057382W WO2014166526A1 WO 2014166526 A1 WO2014166526 A1 WO 2014166526A1 EP 2013057382 W EP2013057382 W EP 2013057382W WO 2014166526 A1 WO2014166526 A1 WO 2014166526A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- processor
- core
- program
- matrix
- threads
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/26—Functional testing
- G06F11/263—Generation of test inputs, e.g. test vectors, patterns or sequences ; with adaptation of the tested hardware for testability with external testers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3632—Software debugging of specific synchronisation aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2205—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
- G06F11/2236—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test CPU or processors
- G06F11/2242—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test CPU or processors in multi-processor systems, e.g. one processor becoming the test master
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
Die Erfindung betrifft ein Verfahren zum Betreiben eines Mehrkern-Prozessorsystems (10), wobei unterschiedliche Threads (26, 28, 30) eines Programms zeitgleich durch jeweils einen anderen Prozessorkern (12, 14, 16) des Mehrkern-Prozessorsystems (10) ausgeführt werden. In einem ersten der Threads (26) wird ein Breakpoint (32) eingefügt, durch welchen der erste Prozessorkern (12) unterbrochen wird und er stattdessen eine Exception-Handling-Routine (36) ausführt. Durch die Exception-Handling-Routine (36) wird anhand einer Zuordnungsmatrix (34) zumindest ein zusätzlich zu unterbrechender Prozessorkern (14, 16) ermittelt und an diesen (14,16) durch die Exception-Handling-Routine (36) ein Inter-Prozessor-Interrupt (IPI) zum Unterbrechen dieses Prozessorkerns (14, 16) gesendet.
Description
Beschreibung
Mehrkern-Prozessorsystem mit Fehleranalysefunktion Die Erfindung betrifft ein Verfahren zum Betreiben eines Mehrkern-Prozessorsystems, durch welches unterschiedliche Threads (Programmteile oder Programmfäden) eines Programms zeitgleich durch mehrere Prozessorkerne des Mehrkern- Prozessorsystems ausgeführt werden, wobei jeder Prozessorkern einen anderen der Threads ausführt. Zu der Erfindung gehört auch ein Mehrkern-Prozessorsystem mit einer Debugging- Einrichtung für eine Programmanalyse des Programms. Schlie߬ lich gehört zu der Erfindung noch ein Computerprogrammpro¬ dukt, mittels welchem ein herkömmliches Mehrkern- Prozessorsystem im Sinne des erfindungsgemäßen Verfahrens ertüchtigt werden kann.
Ein Computer kann für die Bereitstellung des sogenannten „echten" Multitaskings mehrere Prozessoren oder auch einen Prozessor mit mehr als einem Prozessorkern umfassen. Eine solche Anordnung aus mehreren Prozessoren und/oder mehreren Prozessorkernen innerhalb eines Prozessors wird hier als Mehrkern-Prozessorsystem bezeichnet. Durch ein solches Mehrkern-Prozessorsystem werden einzelne, unabhängig voneinander ausführbare Programmteile (Threads) echtparallel ausgeführt, das heißt zeitgleich. Programme, die intern aus mehreren Threads bestehen, können auf nahezu beliebig vielen solcher Prozessorkerne verteilt werden, sodass immer mehr als nur ein Thread aktiv ist.
Viele solcher Programme, die so aufgebaut sind, sind aber bisher oft nur auf sogenannten Einkern-Prozessorsystemen ausgeführt worden. Durch ein Einkern-Prozessorsystem kann nur ein Pseudo-Multitasking bereitgestellt werden. Hierbei werden die einzelnen Threads eines Programms im schnellen Wechsel nacheinander ausgeführt, so dass keine echte zeitliche Paral¬ lelität vorliegt. Wird ein solches Programm nun auf einem Mehrkern-Prozessorsystem ausgeführt, so kann dies zu völlig
neuen Fehlerbildern führen, wenn das Programm nicht an allen Stellen für ein Mehrkern-Prozessorsystem korrekt strukturiert ist . Die Fehlersuche nennt man Debugging (Fehler = Bug) . Der Auf¬ bau eines Debuggers besteht in der Regel aus zwei Teilen: dem Frontend, das dem Programmierer verschiedene Möglichkeiten zur Steuerung der Fehleranalyse bietet, und dem Backend, das sich dann um die Ausführung dieser Steuerkommandos kümmert, während das Frontend unbeeinflusst weiterläuft. Diese beiden Einheiten (Frontend und Backend) sind selbst Programme und können auch auf anderen Computern als dem Mehrkern- Prozessorsystem laufen, was speziell im Bereich von Embedded- Systemen verbreitet ist.
Eine zusätzliche, mögliche Realisierungsform einer Backend- Einheit sind sogenannte Debug-Probes . Diese Hardware- Schaltung bearbeitet Debug-Befehle oder Debug-Anweisungen des Frontends und gibt sie über spezielle Hardware-Debug- Schnittstellen an das Mehrkern-Prozessorsystem weiter. Ein
Beispiel für ein solches Debugging-System ergibt sich aus dem JTAG-Standard (Joint Test Action Group, IEEE-Standard
1149.1). Bei Mehrkern-Prozessorsystemen lassen sich hierbei die Prozessorkerne einzelne ansprechen.
Ein Debugging bietet im Allgemeinen zwei wesentliche Mecha¬ nismen, die ein laufendes Programm anhalten, also die Ausführung des Programms auf einem Prozessorkern unterbrechen. Entweder wird es von außen angehalten (Stop) oder zuvor im Pro- grammcode des Programms wurde eine Unterbrechungsstelle
(Breakpoint) gesetzt, der das Programm stoppt, wenn der Pro¬ grammzähler des betreffenden Prozessorkerns diesen Punkt erreicht, unabhängig davon, in welchem Thread sich das Programm gerade befindet. Anschließend gibt es im Wesentlichen auch zwei Möglichkeiten, wie das Programm fortgesetzt wird. Entwe¬ der wird nur ein einzelner Befehl im aktuellen Thread ausgeführt (Single Step) und der Prozessor dann wieder unterbro-
chen oder das Programm wird im Ganzen fortgesetzt (Continue- Befehl) , was auch wieder zu Thread-Wechseln führen kann.
Bei Einzelkern-Prozessorsystemen hält bei beiden Unterbre- chungsmöglichkeiten der gesamte Prozessor an, d.h. das Programm an sich wird nicht weiter ausgeführt, so dass sicherge¬ stellt ist, dass alle Threads und damit alle Daten des Pro¬ gramms, die den aktuellen Programmzustand beschreiben, sich exakt in dem Zustand befinden, der beim Anhalten des einen Threads vorliegt. Beim Weiterlaufen per Single-Step-Befehl ändern sich ebenfalls nur diejenigen Programmdaten, die der aktuelle Thread durch den einen Programmschritt verändert.
Dies alles trifft bei Mehrkern-Prozessorsystemen nicht mehr zu, so dass sich einige Probleme ergeben, um das Programm in einem konsistenten Zustand anzuhalten und aus den Programmdaten verlässliche Rückschlüsse auf mögliche Fehlerursachen ziehen zu können. Verteilen sich nämlich die Threads des Programms auf mehrere Prozessorkerne und wird dann die Ausfüh- rung eines Threads unterbrochen, weil der Thread auf einem
Breakpoint läuft, hält zunächst auch nur dieser eine Prozes¬ sorkern an, während alle anderen Prozessorkerne und somit auch die anderen Threads des Programms weiterlaufen, d.h. durch die übrigen Prozessorkerne weiter ausgeführt werden. Um das Weiterlaufen zu verhindern, muss ein Debugger nach Erkennen einer Programmunterbrechung in einem Prozessorkern auch die übrigen Prozessorkerne anhalten. Hierzu nutzt man den folgenden Mechanismus. Läuft ein Thread auf einem Breakpoint, so wird in dem betroffenen Prozessorkern eine Ausnahmebehand- lung ausgelöst, d.h. es wird eine sogenannte Exception-
Handling-Routine durch den betroffenen Prozessorkern abgearbeitet. Durch diese Routine wird das Ereignis an das Backend des Debuggers gemeldet, welches wiederum das Ereignis an das Frontend weitergibt. Das Frontend hat die entsprechenden In- formationen über die Threads und die Prozessorkerne, so dass es die Prozessorkerne, auf denen die übrigen Threads des gleichen Programms ablaufen, ebenfalls über ein Kommando an das Backend anhalten kann.
Dieser Vorgang dauert aber in der Größenordnung von Millisekunden, was dazu führen kann, dass das zu analysierende Pro¬ gramm in manchen Threads schon sehr viel weiter ist, als es zum Zeitpunkts des Unterbrechens am Breakpoint in dem einen Thread war. Ebenso können ganz andere Threads inzwischen aktiv sein und sich Threads sogar beendet haben. Dies gilt ins¬ besondere, da moderne Prozessoren Taktfrequenzen im Gigahertz-Bereich haben, so dass pro Millisekunde ca. 1 Million Befehle ausgeführt werden. Daher kann über diesen Weg keine konsistente Angabe der Programmdaten in dem Programm beim Erreichen eines Breakpoints hergestellt werden. Des Weiteren ist auch ungeklärt, was bei einem Single-Step-Befehl in einem Mehrkern-Prozessorsystem eigentlich passieren soll. Läuft nur der eine Thread, der die Unterbrechung verursacht hat, einen Programmschritt weiter oder sollen alle Threads, die gerade auf den anderen Prozessorkernen aktiv sind, ebenfalls um einen Programmschritt weiter ausgeführt werden? Der Erfindung liegt die Aufgabe zugrunde, bei einem Mehrkern- Prozessorsystem eine genauere Fehleranalyse (Debugging) für ein Programm mit mehreren Threads bereitzustellen.
Die Aufgabe wird durch ein Verfahren gemäß Patentanspruch 1, ein Mehrkern-Prozessorsystem gemäß Patentanspruch 9 sowie ein Computerprogrammprodukt gemäß Patentanspruch 10 gelöst. Vor¬ teilhafte Weiterbildungen der Erfindung sind durch die Unteransprüche gegeben. Das erfindungsgemäße Verfahren geht von der eingangs be¬ schriebenen Situation aus, dass unterschiedliche Threads des zu analysierenden Programms zeitgleich durch jeweils einen anderen Prozessorkern des Mehrkern-Prozessorsystems ausge¬ führt werden. Bei dem Verfahren wird nun in an sich bekannter Weise in einen ersten der Threads, der von einem ersten der Prozessorkerne ausgeführt wird, ein Breakpoint eingeführt. Diese Steuermöglichkeit zum gezielten Unterbrechen eines Threads ist im Folgenden zusammenfassend als Debug-Anweisung
bezeichnet. Durch eine solche Debug-Anweisung wird also bei Ausführen der Debug-Anweisung durch den ersten Prozessorkern dieser dazu gebracht, das Ausführen des ersten Threads zu un¬ terbrechen. Gemäß heutigem Hardware-Standard führt ein Pro- zessorkern bei Erreichen einer Debug-Anweisung anstelle des Threads dann eine Exception-Handling-Routine aus.
Bei dem erfindungsgemäßen Verfahren wird nun (bevorzugt vor dem Start des Programms) eine Zuordnungsliste oder Zuord- nungsmatrix bereitgestellt, welche festlegt, welcher andere Prozessorkern zusätzlich unterbrochen werden soll, wenn der erste Prozessorkern unterbrochen wird, d.h. wenn der erste Prozessorkern gemäß der Debug-Anweisung das Ausführen des ersten Threads unterbricht. Des Weiteren ist die genannte Ex- ception-Handling-Routine des ersten Prozessors dazu ausge¬ legt, anhand dieser Zuordnungsmatrix mindestens einen zusätzlich zu unterbrechenden Prozessorkern zu ermitteln. Mit anderen Worten wird die Entscheidung darüber, welche anderen Prozessorkerne noch anzuhalten sind, nicht, wie im Stand der Technik, durch Informieren des Backends und weiter durch Informieren des Frontends ermittelt, sondern unmittelbar durch die Exception-Handling-Routine, und zwar anhand der Zuord¬ nungsmatrix. Um dabei in einem Mehrkern-Prozessorsystem auch eine schnellere Reaktion der ermittelten übrigen Prozessor- kerne zu erhalten, sieht das erfindungsgemäße Verfahren des Weiteren vor, an diesen zumindest einen ermittelten Prozessorkern einen Inter-Prozessor-Interrupt (IPI) zum Unterbre¬ chen dieses Prozessorkerns zu senden. Ein solches IPI-Signal wird direkt über Leitungen, die insbesondere zwischen den Prozessorkernen verlaufen, an die anderen Prozessorkerne übertragen. Das IPI-Signal kann durch die Exception-Handling- Routine des ersten Prozessorkerns ausgelöst werden. Dieser Vorgang dauert nur wenige Nanosekunden, so dass die Threads auf den anderen Prozessorkernen nur sehr wenige Befehle wei- tergelaufen sind und die Programmdaten so konsistent wie mög¬ lich sind.
Indem das erfindungsgemäße Verfahren hardwarebasiert die vor¬ handenen Mechanismen des Exception-Handlings einerseits und des Inter-Prozessor-Interrupts andererseits kombiniert, er¬ gibt sich ein neuartiges flexibles Debug-System, das in einem Mehrkern-Prozessorsystem für Datenkonsistenz sorgt, ohne dass hierzu das zu analysierende (zu debuggende) Programm näher gekannt werden muss. Das erfindungsgemäße Verfahren weist so¬ mit den Vorteil auf, dass zwischen dem Erreichen einer Debug- Anweisung in einem Thread auf einem ersten Prozessorkern und dem Anhalten der übrigen Prozessorkerne nur wenige Nanosekun- den (höchstens eine Mikrosekunde) vergehen, während durch ei¬ ne Unterbrechung, die durch das Backend oder sogar Frontend gesteuert wird, mehr als eine Millisekunde oder sogar bis zu einer Sekunde Zeit vergeht. Somit sind durch das erfindungs- gemäße Verfahren nicht nur der erste Thread, sondern auch die übrigen Threads in nahezu dem Zustand, wie sie ihn aufwiesen, als die Debug-Anweisung im ersten Thread ausgeführt wurde. Ein weiterer Vorteil ergibt sich, dass durch die Zuordnungs¬ matrix gezielt ausgewählt werden kann, welche übrigen Prozes- sorkerne angehalten werden. Es ist hier nicht nötig, alle zu dem Programm gehörigen Threads anzuhalten.
Erst nach dem Anhalten aller ausgewählten Prozessorkerne, d.h. nach dem Unterbrechen der jeweiligen auf den Prozessor- kernen ausgeführten Threads, werden dann bevorzugt das Backend und in dessen Folge das Frontend über das Anhalten des Programms informiert. Hierzu wird gemäß einer Ausführungsform des Verfahrens ein die Unterbrechung signalisierendes Signal an das Backend und/oder das Frontend des Debuggers abgegeben. Durch diese Weiterbildung ergibt sich der Vorteil, dass das Frontend in derselben Weise ausgestaltet sein kann wie ein herkömmliches Frontend, außer dass nun für das Frontend kon¬ sistentere Programmdaten vorliegen. Bevorzugt wird durch die Zuordnungsmatrix nicht nur für einen, sondern für mehrere der Prozessorkerne festgelegt, wel¬ che andere Prozessorkerne jeweils bei Erreichen einer Debug- Anweisung angehalten werden sollen. Hierbei muss nicht einmal
festgelegt sein, dass diese anderen Prozessorkerne ebenfalls angehalten werden sollen. Es kann hier auch eine andere Reaktion festgelegt werden. Läuft also irgendein Prozessorkern auf einem Breakpoint, so steht in der Zuordnungsmatrix, wel- che anderen Prozessorkerne in diesem Fall ebenfalls angehal¬ ten werden sollen oder in sonstiger Weise informiert werden sollen. Die Zuordnungsmatrix muss dabei auch nicht symmetrisch sein, so dass z.B. zwar Prozessorkern N anhält, wenn Prozessorkern M auf einem Breakpoint läuft, aber nicht umge- kehrt. Hierdurch ergibt sich der Vorteil, dass durch Bilden einer geeigneten Zuordnungsmatrix gezielt Fehler lokalisiert werden können, indem beispielsweise einmal ein Thread von ei¬ nem anderen Thread unterbrochen wird und ein anderes Mal nicht. Auch kann im Zusammenhang mit einem Single-Step-Befehl durch die Zuordnungsmatrix festgelegt werden, ob ein bestimmter anderer Prozessorkern ebenfalls einen einzelnen Programmschritt parallel ausführen soll oder nicht. Auch dabei kann die Zuordnungsmatrix asymmetrisch sein, um sicherzustellen, dass die Daten inhaltlich und zeitlich konsistent bleiben.
Die Zuordnungsmatrix kann auch dazu genutzt werden festzulegen, was passieren soll, wenn nach dem Unterbrechen des ersten Prozessorkerns und des zumindest einen zusätzlich ermit¬ telten Prozessorkerns ein Debugger ein Continue-Signal er- zeugt. Gemäß einer Ausführungsform des Verfahrens wird hier durch den Debugger oder durch einen der unterbrochenen Prozessorkerne anhand der Zuordnungsmatrix ermittelt, an welche der Prozessorkerne das Continue-Signal weitergeleitet werden soll. Gemäß der Zuordnungsmatrix wird also dann das Continue- Signal nicht nur an einen, sondern an mehrere der unterbro¬ chenen Prozessorkerne geleitet. Hierdurch ergibt sich der Vorteil, dass die unterbrochenen Prozessorkerne auch wieder synchron die Abarbeitung ihres jeweiligen Threads beginnen. Gemäß einer Ausführungsform des Verfahrens wird entsprechen durch den Debugger oder durch einen der unterbrochenen Prozessorkerne anhand der Zuordnungsmatrix ermittelt, an welche der Prozessorkerne ein Single-Step-Befehl weitergeleitet wer-
den soll, der nach dem Unterbrechen des ersten Prozessorkerns und des zumindest einen zusätzlich ermittelten Prozessorkerns durch einen Debugger erzeugt worden ist. Gemäß der Zuordnungsmatrix wird also dann der Single-Step-Befehl nicht nur an einen, sondern an mehrere der unterbrochenen Prozessorkerne geleitet. Hierdurch ergibt sich der Vorteil, dass die un¬ terbrochenen Prozessorkerne auch wieder synchron die Abarbeitung ihres jeweiligen Threads um einen Befehl weiter durchführen .
Die Zuordnungsmatrix kann beispielsweise im Backend-Programm definiert und beispielsweise von einem Benutzer im Frontend konfiguriert werden. So kann ein Benutzer festlegen, wie diese Zuordnungsmatrix individuell beschreibt, welche Prozessor- kerne auf Aktionen eines anderen wie reagieren sollen.
Hierbei muss darauf geachtet werden, dass gemäß dem Verfahren zunächst einmal nur festgelegt wird, welcher andere Prozes¬ sorkern angehalten werden soll. Oft ist man aber nicht an ei- nem bestimmten Prozessorkern, sondern an einem bestimmten Thread interessiert, der ebenfalls angehalten werden soll, wenn ein bestimmter anderer Thread durch einen Debug- Anweisung unterbrochen wird. Es muss also sichergestellt sein, dass der richtige Thread auf dem unterbrochenen Prozes- sorkern ausgeführt wird. Hierzu wird gemäß einer Ausführung des Verfahrens durch eine Konfigurationseinrichtung, also beispielsweise den Debugger (manuell im Frontend oder automa¬ tisch im Backend) , vor dem Start des Programms ermittelt, welche Threads in Bezug auf das Unterbrechen voneinander ab- hängig sein sollen, und festgelegt, welcher der Threads durch welchen der Prozessorkerne ausgeführt werden soll. Die Zuord¬ nungsmatrix wird dann entsprechend der ermittelten Abhängigkeit erzeugt und die Threads zu den richtigen Prozessorkernen zugeordnet. Das Zuordnen von Threads zu bestimmten Prozessor- kernen ist an sich aus dem Stand der Technik bekannt.
Die Zuordnungsmatrix kann gemäß einer Weiterbildung des Verfahren aber auch jederzeit durch einen Debugger, insbesondere
ein Frontend eines Debuggers, oder eine andere Institution geändert werden, wenn z.B. die Analyse des zu debuggenden Programms dies erfordert. Dazu muss das zu debuggende Pro¬ gramm in vorteilhafter Weise nicht neu gestartet werden. Die Zuordnungsmatrix kann also zum einen vor dem Programmstart definiert werden, aber auch später während des Debuggens des Programms erneut verändert werden.
Wie bereits ausgeführt, gehört zu der Erfindung auch ein Mehrkern-Prozessorsystem mit einer Debugging-Einrichtung . Diese Debugging-Einrichtung ist dazu ausgelegt, zum einen eine Exception-Handling-Routine zumindest eines Prozessorkerns des Mehrkern-Prozessorsystems festzulegen und zum anderen ei¬ ne Zuordnungsmatrix für die Exception-Handling-Routine be¬ reitzustellen. Des Weiteren ist die Debugging-Einrichtung dazu ausgelegt, das Mehrkern-Prozessorsystem gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens zu betreiben.
Schließlich gehört zu der Erfindung auch ein Computerprogrammprodukt, mittels welchem ein herkömmliches Mehrkern- Prozessorsystem ebenfalls in der Weise betrieben werden kann wie ein Mehrkern-Prozessorsystem gemäß der Erfindung. Hierzu ist auf einem Speichermedium, beispielsweise einer CD-ROM oder einer Festplatte, ein Debugging-Programm bereitgestellt, welches dazu ausgelegt ist, bei Ausführung des Debugging- Programms durch ein Mehrkern-Prozessorsystem eine Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Wie bereits eingangs ausgeführt, kann insbesondere bei einem En- bedded-System das Debugging-Programm auch auf einem mit dem Mehrkern-Prozessorsystem gekoppelten Computersystem ausgeführt werden. Auch diese Ausführungsform des Debugging- Programms ist von dem erfindungsgemäßen Programmprodukt um- fasst .
Im Folgenden ist die Erfindung noch einmal anhand eines konkreten Ausführungsbeispiels erläutert. Die FIGUR zeigt hierzu ein Mehrkern-Prozessorsystem oder kurz System 10, das beispielsweise ein Entwicklungssystem für Embedded-Anwendungen
sein kann. Das System 10 weist mehrere (hier beispielhaft drei) Prozessorkerne 12, 14, 16 (Core 1, Core 2, Core 3) auf, einen Speicher 18 und eine Debugging-Einrichtung 20 mit einem Backend 22 (BE) und einem Frontend 24 (FE) . Die Prozessorker- ne 12, 14, 16 sind über Interrupt-Leitungen II, 12, 13 miteinander verbunden.
Die Debugging-Einrichtung 20 kann beispielsweise ein Programmmodul für das Backend 22 und ein Programmmodul für das Frontend 24 umfassen. Die Debugging-Einrichtung 20 kann beispielsweise durch einen weiteren (hier nicht dargestellten) Prozessorkern ausgeführt werden.
Durch die Prozessorkerne 12, 14, 16 wird ein Programm ausge- führt, das mittels der Debugging-Einrichtung 20 analysiert werden soll. Das Programm umfasst in dem Beispiel drei
Threads (THRD) 26, 28, 30, von denen der Thread 26 (THRD n) von dem Prozessorkern 12, der Thread 28 (THRD m) durch den Prozessorkern 14 und der Thread 30 (THRD k) durch den Prozes- sorkern 16 ausgeführt wird. Eine (nicht dargestellte) Bedien¬ person gibt für die Analyse an dem Frontend 24 ein, dass die Ausführung des Threads 26 durch den Prozessorkern 12 an einer bestimmten Stelle im Programmtext des Threads 26 unterbrochen werden soll. Hierzu setzt die Bedienperson in an sich bekann- ter Weise einen Breakpoint 32, d.h. sie kennzeichnet eine
Programmstruktur im Thread 26, an welcher die Ausführung des Threads 26 unterbrochen werden soll. Die Eingabe der Bedienperson wird von dem Frontend 24 an das Backend 22 weitergege¬ ben, welches den Breakpoint 32 als eine Debug-Anweisung im Programmcode des Threads 26 einfügt.
Wenn der Breakpoint 32 beim Ausführen des Threads 26 durch den Prozessorkern 12 erreicht wird, soll aber nicht nur der Thread 26 angehalten werden, sondern auch die übrigen Threads 28, 30 des Programms sollen möglichst schnell, d.h. möglichst zum selben Zeitpunkt oder zumindest nur wenige Taktzyklen später angehalten werden.
Die Abschaltung der anderen Prozessorkerne 14, 16 des Mehrkern-Prozessorsystems 10 durch das Debugger-Frontend 24 oder auch durch eine Hardware-Probe, wie sie aus dem Stand der Technik bekannt ist, ist hierzu viel zu langsam, da speziell im Fall eines Echtzeitsystems die anderen Prozessorkerne 14, 16 zu viele Befehle verarbeiten, bis sie angehalten werden. Dies führt zu einer inkonsistenten und damit für die Bedienperson zum Analysieren des Programms unbrauchbaren Repräsentation der Programmdaten.
Bei dem System 10 ist daher eine Lösung über eine von außen, d.h. über die Debugging-Einrichtung 20, programmierbare Prozessorkern-Aktion-Matrix (Core/Action-Matrix) oder kurz Matrix 34 bereitgestellt. Die Matrix 34 ist Bestandteil einer Exception-Handling-Routine (EHR) oder kurz Debug-Routine 36. Die Matrix 34 ist eine Zuordnungsmatrix.
Die Debug-Routine 36 kann von der Debugging-Einrichtung 20, beispielsweise in dem Backend 22, im Speicher 18 abgespei- chert worden sein. Für den Prozessorkern 12 ist z.B. in einem Register eine Sprungadresse 38 beispielsweise ebenfalls durch die Debugging-Einrichtung 20, insbesondere das Backend 22, festgesetzt worden, welche auf einen Startpunkt der Debug- Routine 36 im Speicher 18 weist. Sobald der Prozessorkern 12 den Breakpoint 32 bei der Ausführung des Threads 26 erreicht, unterbricht er die Ausführung des Threads 26 und führt den Programmcode aus, der an der Speicheradresse beginnt, auf welche die Sprungandresse 38 weist (in der Figur als Ereignis „Debug" symbolisiert) . Mit anderen Worten führt der Prozes- sorkern 12 die Debug-Routine 36 aus. Durch die Debug-Routine 36 wird der Prozessorkern 12 dahingehend gesteuert, dass er über die Interrupt-Leitungen II, 12 ein Inter-Prozessor- Interrupt-Signal (IPI) an die anderen Prozessorkerne 14, 16 sendet, wodurch diese ebenfalls das Abarbeiten der jeweiligen Threads 28, 30 unterbrechen. Welche Prozessorkerne durch das IPI-Signal unterbrochen werden sollen, wird durch die Debug- Routine 36 anhand der Matrix 34 ermittelt. Die in der FIGUR gezeigte Matrix zeigt hierbei nur exemplarisch die Wirkung
der Matrix 34. Der Thread n (26) läuft auf Breakpoint 32 und löst somit die Debug-Exception aus. Die Debug-Routine 36 wer¬ tet die Matrix 34 aus und erhält daraus die Information, dass bei Auftreten eines Breakpoints 32 im Prozessorkern 12 (Core 1) die Prozessorkerne 14 und 16 (Core 2, Core 3) anzuhalten sind (siehe die erste Zeile 40 der Matrix 34) . Entsprechend werden durch die Debug-Routine 36 bei ihrer Ausführung durch den Prozessorkern 12 die Prozessorkerne 14 und 16 bzw. die Threads m und k (28, 30) per IPI-Signal angehalten. In der Matrix 34 können entsprechende Aktionen für die Fälle eines
Single-Step-Befehls (Zeile „Single Step") und eines Continue- Befehls (Zeile „Continue") definiert sein.
Der sich hierbei ergebende Nachlauf zwischen dem Erreichen des Breakpoints 32 und dem Anhalten der Prozessorkerne 14 und 16 ist nur wenige Taktzyklen lang, d.h. es werden nur wenige Befehle der Threads 28, 30 nach dem Erreichen des Breakpoints 32 ausgeführt, so dass der Zustand der Prozessorkerne 14 und 16 zum entscheidenden Zeitpunkt des Erreichens des Break- points 32 durch den Prozessorkern 12 sich nur geringfügig vom Zustand der Prozessorkerne 14, 16 bei deren Anhalten unter¬ scheidet. Aus einer Analyse des Programmcodes der Threads 28, 30 können sogar die letzten Veränderungsschritte rückgängig gemacht werden, so dass der Zustand der angehaltenen Threads 28, 30 zum Zeitpunkt des Erreichens des Breakpoints 32 rekon¬ struiert werden kann.
Die Lösung über eine von außen programmierbare Matrix 34 bie¬ tet also sowohl durch ihre Flexibilität als auch durch die Realisierung in der Ausnahmebehandlung des Prozessors (Excep- tion-Handling-Routine) die notwendige Geschwindigkeit, um die anderen betroffenen Prozessorkerne mit so wenig Verzögerung wie möglich anzuhalten. Weitere Vorteile ergeben sich aus der zulässigen Asymmetrie der Matrix, so dass das Anhalten eines Prozessorkerns zwar andere ebenfalls anhält, aber nicht unbe¬ dingt umgekehrt, falls einer der anderen Prozessorkerne an¬ hält .
Bezugs zeichenliste
10 Mehrkern-Prozessorsystem
12, 14, 16 Prozessorkern
18 Speicher
20 Debugging-System
22 Backend
24 Frontend
26, 28, 30 Thread
32 Breakpoint
34 Zuordnungsmatrix
36 Exception-Handling-Routine
38 Sprungadresse
40 Matrixzeile
Debug Debug-Ereignis
II, 12, 13 Interrupt-Leitung
IPI Inter-Prozess- Interrupt-Signal
Claims
1. Verfahren zum Betreiben eines Mehrkern-Prozessorsystems (10), wobei unterschiedliche Threads (26, 28, 30) eines Pro- gramms zeitgleich durch jeweils einen anderen Prozessorkern (12, 14, 16) des Mehrkern-Prozessorsystems (10) ausgeführt werden und bei dem Verfahren
- in einen ersten der Threads (26), der von einem ersten der Prozessorkerne (12) ausgeführt wird, ein Breakpoint (32) als Debug-Anweisung (32) eingefügt wird, wobei bei Ausführen der Debug-Anweisung (32) durch den ersten Prozessorkern (12) dieser das Ausführen des ersten Threads (26) unterbricht und stattdessen eine Exception-Handling-Routine (36) ausführt, dadurch gekennzeichnet, dass
- eine Zuordnungsmatrix (34) bereitgestellt wird, welche festlegt, welcher andere Prozessorkern (14, 16) zusätzlich unterbrochen werden soll, wenn der erste Prozessorkern (12) gemäß der Debug-Anweisung das Ausführen des ersten Threads (26) unterbricht, und
- durch die Exception-Handling-Routine (36) des ersten Pro¬ zessorkerns (12) anhand der Zuordnungsmatrix (34) zumindest ein zusätzlich zu unterbrechender Prozessorkern (14, 16) ermittelt und an den zumindest einen ermittelten Prozessorkern (14, 16) durch die Exception-Handling-Routine (36) ein Inter- Prozessor-Interrupt (IPI) zum Unterbrechen dieses Prozessor¬ kerns (14, 16) gesendet wird.
2. Verfahren nach Anspruch 1, wobei erst nach dem Unterbrechen des ersten und des zumindest einen ermittelten Prozes- sorkerns (12, 14, 16) ein die Unterbrechung signalisierendes Signal an ein Backend (22) und/oder ein Frontend (24) einer Debugging-Einrichtung (20) abgegeben wird.
3. Verfahren nach einem der vorhergehenden Ansprüche, wobei durch die Zuordnungsmatrix (34) für mehrere der Prozessorkerne (12, 14, 16) festgelegt wird, welche anderen Prozessorkerne (12, 14, 16) jeweils bei einer Unterbrechung wegen einer Debug-Anweisung (32) wie reagieren.
4. Verfahren nach Anspruch 3, wobei eine asymmetrische Zuord¬ nungsmatrix (34) bereitgestellt wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei nach dem Unterbrechen des ersten Prozessorkerns (12) und des zumindest einen ermittelten Prozessorkerns eine Debugging- Einrichtung (20) ein Continue-Signal erzeugt und durch die Debugging-Einrichtung (20) oder durch einen der unterbroche- nen Prozessorkerne (12, 14, 16) anhand der Zuordnungsmatrix (34) ermittelt wird, an welche der Prozessorkerne (12, 14, 16) das Continue-Signal weitergeleitet werden soll, und gemäß der Zuordnungsmatrix (34) das Continue-Signal an mehrere der unterbrochenen Prozessorkerne (12, 14, 16) geleitet wird.
6. Verfahren nach einem der vorhergehenden Ansprüche, wobei nach dem Unterbrechen des ersten Prozessorkerns (12) und des zumindest einen ermittelten Prozessorkerns eine Debugging- Einrichtung (20) einen Single-Step-Befehl erzeugt und durch die Debugging-Einrichtung (20) oder durch einen der unterbrochenen Prozessorkerne (12, 14, 16) anhand der Zuordnungsmat¬ rix (34) ermittelt wird, an welche der Prozessorkerne (12, 14, 16) der Single-Step-Befehl weitergeleitet werden soll, und gemäß der Zuordnungsmatrix (34) der Single-Step-Befehl an mehrere der unterbrochenen Prozessorkerne (12, 14, 16) gelei¬ tet wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei vor dem Start des Programms durch eine Konfigurationseinrich- tung (20)
a) ermittelt wird, welche Threads (26, 28, 30) in Bezug auf das Unterbrechen voneinander abhängig sind, und
b) festgelegt wird, welcher der Threads (26, 28, 30) durch welchen der Prozessorkerne (12, 14, 16) ausgeführt werden soll, und
c) entsprechend der ermittelten Abhängigkeit die Zuordnungs¬ matrix (34) erzeugt wird und die Threads (26, 28, 30) zu den Prozessorkernen zugeordnet werden.
8. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Zuordnungsmatrix (34) nach dem Start des Programms verändert wird.
9. Mehrkern-Prozessorsystem (10) mit einer Debugging- Einrichtung (20), die dazu ausgelegt ist, eine Exception- Handling-Routine (36) zumindest eines Prozessorkerns (12) des Mehrkern-Prozessorsystems (10) und eine Zuordnungsmatrix (34) bereitzustellen und das Mehrkern-Prozessorsystem (10) gemäß einem Verfahren nach einem der vorhergehenden Ansprüche zu betreiben .
10. Computerprogrammprodukt mit einem auf zumindest einem Speichermedium gespeicherten Debuggingprogramm (20), welches dazu ausgelegt ist, bei Ausführen des Debuggingprogramms (20) durch ein Mehrkern-Prozessorsystem (10) oder einem mit diesem Mehrkern-Prozessorsystem (10) gekoppeltes Computersystem ein Verfahren nach einem der Ansprüche 1 bis 8 durchzuführen.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/783,251 US9952954B2 (en) | 2013-04-09 | 2013-04-09 | Multicore processor system having an error analysis function |
EP13717466.0A EP2962205B1 (de) | 2013-04-09 | 2013-04-09 | Mehrkern-prozessorsystem mit fehleranalysefunktion |
PCT/EP2013/057382 WO2014166526A1 (de) | 2013-04-09 | 2013-04-09 | Mehrkern-prozessorsystem mit fehleranalysefunktion |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2013/057382 WO2014166526A1 (de) | 2013-04-09 | 2013-04-09 | Mehrkern-prozessorsystem mit fehleranalysefunktion |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2014166526A1 true WO2014166526A1 (de) | 2014-10-16 |
Family
ID=48142749
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2013/057382 WO2014166526A1 (de) | 2013-04-09 | 2013-04-09 | Mehrkern-prozessorsystem mit fehleranalysefunktion |
Country Status (3)
Country | Link |
---|---|
US (1) | US9952954B2 (de) |
EP (1) | EP2962205B1 (de) |
WO (1) | WO2014166526A1 (de) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105224454A (zh) * | 2015-09-25 | 2016-01-06 | 华为技术有限公司 | 一种调试方法、多核处理器和调试设备 |
CN105354136A (zh) * | 2015-09-25 | 2016-02-24 | 华为技术有限公司 | 一种调试方法、多核处理器和调试设备 |
CN105354105A (zh) * | 2015-10-28 | 2016-02-24 | 上海斐讯数据通信技术有限公司 | 软件异常处理***及方法 |
CN109726135A (zh) * | 2019-01-25 | 2019-05-07 | 杭州嘉楠耘智信息科技有限公司 | 一种多核调试方法、装置及计算机可读存储介质 |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2580136B (en) | 2018-12-21 | 2021-01-20 | Graphcore Ltd | Handling exceptions in a multi-tile processing arrangement |
GB2583574B (en) * | 2018-12-21 | 2021-05-19 | Graphcore Ltd | Handling Exceptions in a Multi-Tile Processing Arrangement |
CN112256502B (zh) * | 2020-09-25 | 2023-11-21 | 新华三半导体技术有限公司 | 一种内存性能测试方法、装置及芯片 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060282707A1 (en) * | 2005-06-09 | 2006-12-14 | Intel Corporation | Multiprocessor breakpoint |
US20070180322A1 (en) * | 2006-01-11 | 2007-08-02 | Seiko Epson Corporation | Debug support device, and program for directing computer to perform debugging method |
US20080115113A1 (en) * | 2006-11-15 | 2008-05-15 | Lucian Codrescu | Non-intrusive, thread-selective, debugging method and system for a multi-thread digital signal processor |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5790871A (en) * | 1996-05-17 | 1998-08-04 | Advanced Micro Devices | System and method for testing and debugging a multiprocessing interrupt controller |
US6708326B1 (en) * | 2000-11-10 | 2004-03-16 | International Business Machines Corporation | Method, system and program product comprising breakpoint handling mechanism for debugging and/or monitoring a computer instruction sequence |
-
2013
- 2013-04-09 WO PCT/EP2013/057382 patent/WO2014166526A1/de active Application Filing
- 2013-04-09 US US14/783,251 patent/US9952954B2/en active Active
- 2013-04-09 EP EP13717466.0A patent/EP2962205B1/de active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060282707A1 (en) * | 2005-06-09 | 2006-12-14 | Intel Corporation | Multiprocessor breakpoint |
US20070180322A1 (en) * | 2006-01-11 | 2007-08-02 | Seiko Epson Corporation | Debug support device, and program for directing computer to perform debugging method |
US20080115113A1 (en) * | 2006-11-15 | 2008-05-15 | Lucian Codrescu | Non-intrusive, thread-selective, debugging method and system for a multi-thread digital signal processor |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105224454A (zh) * | 2015-09-25 | 2016-01-06 | 华为技术有限公司 | 一种调试方法、多核处理器和调试设备 |
CN105354136A (zh) * | 2015-09-25 | 2016-02-24 | 华为技术有限公司 | 一种调试方法、多核处理器和调试设备 |
WO2017050287A1 (zh) * | 2015-09-25 | 2017-03-30 | 华为技术有限公司 | 一种调试方法、多核处理器和调试设备 |
WO2017050286A1 (zh) * | 2015-09-25 | 2017-03-30 | 华为技术有限公司 | 一种调试方法、多核处理器和调试设备 |
CN105224454B (zh) * | 2015-09-25 | 2018-06-05 | 华为技术有限公司 | 一种调试方法、多核处理器和调试设备 |
CN105354136B (zh) * | 2015-09-25 | 2018-06-15 | 华为技术有限公司 | 一种调试方法、多核处理器和调试设备 |
US10409709B2 (en) | 2015-09-25 | 2019-09-10 | Huawei Technologies Co., Ltd. | Debugging method, multi-core processor and debugging device |
US10503629B2 (en) | 2015-09-25 | 2019-12-10 | Huawei Technologies Co., Ltd. | Debugging method, multi-core processor, and debugging device |
CN105354105A (zh) * | 2015-10-28 | 2016-02-24 | 上海斐讯数据通信技术有限公司 | 软件异常处理***及方法 |
CN109726135A (zh) * | 2019-01-25 | 2019-05-07 | 杭州嘉楠耘智信息科技有限公司 | 一种多核调试方法、装置及计算机可读存储介质 |
CN109726135B (zh) * | 2019-01-25 | 2022-06-14 | 嘉楠明芯(北京)科技有限公司 | 一种多核调试方法、装置及计算机可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
EP2962205A1 (de) | 2016-01-06 |
US20160062863A1 (en) | 2016-03-03 |
US9952954B2 (en) | 2018-04-24 |
EP2962205B1 (de) | 2018-06-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2014166526A1 (de) | Mehrkern-prozessorsystem mit fehleranalysefunktion | |
DE69225750T2 (de) | Datenverarbeitungssystem mit internem Befehlspufferspeicher | |
DE10297856B4 (de) | Verfahren und Vorrichtung zum Suspendieren der Ausführung eines Threads, bis ein spezifizierter Speicherzugriff auftritt | |
DE2953432C1 (de) | Vorrichtung zum Testen eines Mikroprogramms | |
DE19834191C2 (de) | Integrierte Schaltungsvorrichtung und ihr Steuerverfahren | |
CH660243A5 (de) | Vorrichtung zur ablaufverfolgung eines programms. | |
EP1720100A1 (de) | Verfahren und Vorrichtung zur Emulation einer programmierbaren Einheit | |
EP2575002A1 (de) | Verfahren und Virtualisierungssoftware für die Bereitstellung von unabhängigen Zeitquellen für virtuelle Laufzeitumgebungen | |
DE102012224276B4 (de) | Verzögerte Ausführung auf mehreren Prozessoren | |
DE69815006T2 (de) | Datenverarbeitungseinheit mit Fehlerbeseitungsmöglichkeiten | |
EP0048991B1 (de) | Verfahren und Anordnung zur Behandlung von Unterbrechungsbedingungen während des Arbeitsablaufes in Datenverarbeitungsanlagen mit Mikroprogrammsteuerung | |
WO2011047901A1 (de) | Verfahren und vorrichtung zum testen eines systems mit zumindest einer mehrzahl von parallel ausführbaren softwareeinheiten | |
DE112011100168T5 (de) | Erfassen von Diagnosedaten in einer Datenverarbeitungsumgebung | |
DE69411096T2 (de) | Entwicklungsunterstützungssystem für einen Mikrocomputer mit internem Cachespeicher | |
DE60010847T2 (de) | Verfahren zur Fehlerbeseitigung in einem Thread-Programm | |
DE3037475A1 (de) | Schnittstellenschaltungsanordnung fuer eine datenverarbeitungsanlage | |
DE69422003T2 (de) | Verfahren und Vorrichtung zur Steuerung der Befehlswiederholung | |
DE10139660B4 (de) | Programmgesteuerte Einheit mit Debug-Ressourcen | |
DE10085438B4 (de) | Prozessor mit Wiederholarchitektur mit schnellen und langsamen Wiederholpfaden | |
EP2287742B1 (de) | Programmgesteuerte Einheit | |
WO2004034172A2 (de) | Verfahren zur ereignissynchronisation, damit synchronisierte prozessoren und fehlertoleranter systeme mit derartigen prozessoren | |
DE3202826C1 (de) | Verfahren und Anordnung zur Einleitung einer Fehlersimulation im Zentralprozessor einer Datenverarbeitungsanlge | |
DE2048473C3 (de) | Mit einem Hauptdatenrechner verbundener Fehlerdatenrechner geringerer Leistungsfähigkeit | |
EP1197866B1 (de) | Programmgesteuerte Einheit | |
EP2418581A1 (de) | Verfahren und Analyseeinrichtung zum Auffinden von Fehlern in einem ablaufenden Programm |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 13717466 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2013717466 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 14783251 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: DE |