Debugger im Monitor, wie funktioniert das? (generell)

[Christian B. (casandro)]

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.

[Christian R. (supachris)]

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....

[Christian B. (casandro)]

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.

[Bernhard M. (boregard)]

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

[Frank S. (Firma: HSCS) (linuxerr)]

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.

[AVRFan (Gast)]

>Softwaremäßig wird das üblicherweise so gemacht

Wow, klasse erklärt :-)

[Christian B. (casandro)]

Danke für die guten Erklärungen!

[Marco S. (masterof)]

@Bernhard

Hi

Willst du nicht den Beitrag in die Artikelsammlung stellen und bei dem 
Artikelschreib-Wettbewerb mitmachen?

Gruß Marco