Wie funktioniert eigentlich so ein Debugger im Monitor, wie ihn viele Mikrocomputersysteme haben? Der Monitor muss ja da irgendwie in der Lage sein, einen einzigen Befehl im Programm auszuführen oder das Programm an einer bestimmten Stelle anzuhalten. Wie wird das gemacht? Also auf den ATMegas fällt mir spontan nur eine Möglichkeit ein. Man sorgt für einen Interrupt der genau nach Bearbeitung der Interruptroutine auftritt. So läuft das Programm immer genau einen Programmschritt. Auf vielen Plattformen geht das aber nicht.
Die Debug-Logik im µC hat kompletten Zugriff auf CPU, alle Register, Speicher usw. Sie kann die CPU einen Schritt machen lassen, 100 Schritte, neu Starten, Programmzähler mit beliebigen Werten laden, Register und Speicherstellen lsen und verändern. Desweiteren kann die Hardware-Breakpoints setzen, d.h. wenn der Programmzähler auf einer bestimmten Stelle ankommt, wird die CPU angehalten und die Steuerung dem Debugger übergeben. Das Debug-Modul ist im Normalfall stark mit der CPU verwachsen....
Das mein ich aber nicht. Das ist ja Hardware debugging. Ich hann aber auch auf dem Z80 oder gar dem 8086 debuggen. Da ist (traditionell) keine Debug-Logik im Sinne von JTAG o.Ä. drin.
Hallo, Softwaremäßig wird das üblicherweise so gemacht, daß bei Breakpoints der Maschinencode an der Stelle des Programms durch einen Sprung in den Debugger ersetzt wird. Im Debugger wird dann, wenn dort angehalten wurde, wieder der original Maschinencode zurückgeschrieben. Das geht natürlich nur, wenn der Programmspeicher verändert werden kann. Für Einzelschrittausführung besteht noch die Möglichkeit, einen freien Interrupt zu verwenden, das geht dann auch, wenn der Programmspeicher nicht verwendet werden kann. Man kann da z.B. einen freien Interrupt Pin verwenden. Im Debugger sperrt man die Interrupts, schreibt dann auf den Interrupt-Pin einen Wert, der den Interrupt auslöst, schreibt die auszuführenden Speicheradresse des Programmspeichers als Interrupt-Return Adresse auf den Stack und führt einen "Return from Interrupt" Befehl aus. Der gibt den Interrupt frei, der Return springt and die auszuführende Adresse, führt einen Befehl aus und sprint in die Interrupt-Service Routine, die zum Debugger gehört. Das geht auf den meisten kleineren Prozessoren weil: - üblicherweise nach einem Return-from-Interrupt immer ein Befehl ausgeführt wird und, - alle Maschinen Befehle atomar sind, d.h. eine Maschinenbefehl kann nicht durch einen Interrupt unterbrochen werden (was bei größeren Prozessoren, ab 68000, möglich ist). Diese Varianten habe ich mal auf einen 8051 implementiert, ob das auf dem AVR auch funktioniert weiß ich nicht, dort habe ich kene ich die Interruptfeinheiten noch nicht so gut.. Gruß, Bernhard
das wurde zb so gemacht 1. setzen eines haltepunktes im programm, dazu wurde ein spezieller sprungbefehl (call, jp oder rst) in den ram geschrieben und der dortige op-code gerettet. 2. erreicht das programm den sprungbefehl, führt dieser in das debuggingprogramm, in dem alle register und flags gerettet und angezeigt werden. 3. auf knopfdruck wird der alte opcode wieder zurückgeladen die register und flags wieder restauriert und der restaurierte op-code angesprungen.
Gast
#912602
>Softwaremäßig wird das üblicherweise so gemacht
Wow, klasse erklärt :-)
Danke für die guten Erklärungen!
@Bernhard Hi Willst du nicht den Beitrag in die Artikelsammlung stellen und bei dem Artikelschreib-Wettbewerb mitmachen? Gruß Marco
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.