Wie funktioniert ein J-Link?

Stefanus F. schrieb:
> Der Programmierer muss dazu in seinen Quelltext Haltepunkte einfügen

Nö, muss er nicht.
Das macht der JLink automatisch wenn man im Debugger an Stelle xyz einen 
Breakpoint haben will.
Die schreibt er auch nicht in den Programmcode, sondern direkt in 
Flash/RAM.

Bei Prozessoren die aus dem Flash laufen dauert das dann natürlich etwas 
länger, beim laufen aus RAM merkt mans nicht.

Stefanus F. schrieb:
> Der Debugger ersetzt
> direkt im Flash einen "normalen" Befehl durch einen Break Befehl. Wenn
> die CPU dann dort anhält, muss wieder der ursprüngliche Befehl
> hingeschrieben werden, um es fortzusetzen. Es finden also ziemlich viele
> Flash-Zugriffe statt.

Das muss man beim AVR machen, weil die CPU keine Befehle aus dem RAM 
ausführen kann.

Ich bin mir ziemlich sicher das beim JLink ein anderer Weg für Flash 
Breakpoints gewählt wurde: Die mit Breakpoints überschriebenen Befehle 
werden "simuliert",d.h. deren Seiteneffekte direkt vom Debugger in die 
Hardware geschrieben.

Mw E. schrieb:
> Stefanus F. schrieb:
>> Der Programmierer muss dazu in seinen Quelltext Haltepunkte einfügen
>
> Nö, muss er nicht.
> Das macht der JLink automatisch wenn man im Debugger an Stelle xyz einen
> Breakpoint haben will.

?? Das heißt, ich setze den Brakepoint nicht explizit im Quellcode, 
sondern der Debugger liest meine Gedanken?

> Bei Prozessoren die aus dem Flash laufen dauert das dann natürlich etwas
> länger, beim laufen aus RAM merkt mans nicht.

Auch beim Ausführen aus dem RAM kostet das extra Zeit, die ggf. ein 
Timing durcheinander bringen kann.

Rolf M. schrieb:
> Das heißt, ich setze den Brakepoint nicht explizit im Quellcode,
> sondern der Debugger liest meine Gedanken?

Nein, der Debugger ändert das Programm im Chip, bevor er es ausführt, 
aber nachdem du ihm gesagt hast, wo du den Breakpoint haben willst.

Genau deswegen hat x86 auch eine besondere Codierung für "int 3". Für 
alle anderen Werte braucht er ein zusätzliches Byte...

Rolf M. schrieb:
> Mw E. schrieb:
>> Stefanus F. schrieb:
>>> Der Programmierer muss dazu in seinen Quelltext Haltepunkte einfügen
>>
>> Nö, muss er nicht.
>> Das macht der JLink automatisch wenn man im Debugger an Stelle xyz einen
>> Breakpoint haben will.
>
> ?? Das heißt, ich setze den Brakepoint nicht explizit im Quellcode,
> sondern der Debugger liest meine Gedanken?

Nein in der IDE / im Debugger klickste wie gewohnt die Codezeile an.
Aber ein "__BKPT(n);" muss man eben nicht vorm Compilieren eintippen.
ka mit was stefanus da arbeitet.

Rolf M. schrieb:
> Auch beim Ausführen aus dem RAM kostet das extra Zeit, die ggf. ein
> Timing durcheinander bringen kann.

Mir gings da eher um die Schreibzeit für die Binäränderung im Flash mit 
vorherigem erase.
Beim Flash Breakpoints setzen auf STM32 mit dem JLink blitzt dann mal 
kurz der Programmerfortschrittsbalken auf.

Das allgemeine Timing vom Programm wird natürlich immer beinträchtigt.
Wenn man das nicht will muss man tracen.

Rolf M. schrieb:
>> Nö, muss er nicht.
>> Das macht der JLink automatisch wenn man im Debugger an Stelle xyz einen
>> Breakpoint haben will.
>
> ?? Das heißt, ich setze den Brakepoint nicht explizit im Quellcode,
> sondern der Debugger liest meine Gedanken?

Der Eine muss es hinschreiben, der Andere setzt nur ein Häkchen in der 
IDE.....

Den Jlink edu gibts für 66€ und das lohnt sich! ;)
Oder flash eben mal nen STlink zum mini Jlink um.

Stefanus F. schrieb:
> Frage dazu: Muss das Programm dazu neu compiliert werden?

Normalerweise nicht. Ein "Breakpoint"-Befehl ist meistens so lang wie 
der kürzeste Befehl des Instruction Sets (z.B. x86: "int 3" ist ein 
1-Byte-Befehl). Den kann man also immer irgendwo hinsetzen.

> Wenn nicht, stelle ich mir vor, dass der Breakpoint einen
> bestehenden Befehl überschreibt. Wie wird der ursprüngliche
> Befehl dann beim Fortsetzen ausgeführt?

Der Debugger merkt sich beim Setzen des Breakpoints einfach, welcher 
Befehl da vorher stand. Entweder, er schreibt den Befehl zurück, setzt 
den Program Counter einen Befehl zurück und lässt die CPU weiterlaufen - 
oder er führt den Befehl schlicht selbst aus.

Ersteres macht z.B. DOS DEBUG: Es überschreibt den RAM mit "int 3", 
fängt den Debug-Interrupt ab, stellt das Byte wieder her, repariert den 
CPU-Zustand und setzt die Ausführung fort. Dadurch können auch Programme 
untersucht werden, die Befehle benutzen, die DEBUG nicht kennt.

> Jim M. schrieb:
>> Die mit Breakpoints überschriebenen Befehle werden
>> "simuliert", d.h. deren Seiteneffekte direkt vom Debugger
>> in die Hardware geschrieben.
> Das klingt für mich sehr überraschend. Ist es wirklich so?

Für die meisten Befehle sind die Nebeneffekte überschaubar (Arithmetik, 
Sprünge), daher ist das eine gute Optimierung. Geht natürlich 
prinzipbedingt nicht für alle Befehle.

... schrieb:
>> Den Komfort eines J-Links
>
> Ein J-Link ist nicht komfortabel. Der kann gerademal das
> Allernotwendigste. Ein Trace-Buffer fehlt z.B. voellig.

Du hast hier im Forum schon öfter gezeigt, dass du von nix ne Ahnung 
hast ;)
So langsam sollteste einfach ma leise sein.

Der Jlink is super zum debuggen.
Zum tracen gibts den J-Trace und der kost dann aber richtig Knete.

Stefanus F. schrieb:
> Meine Aussage, dass Breakpoints in das Programm eingefügt werden ist
> aber doch prinzipiell richtig, oder?

Nur bei Softwarebreakpoints ist deine Aussage richtig.

Stefanus F. schrieb:
> Frage dazu: Muss das Programm dazu neu compiliert werden? Wenn nicht,
> stelle ich mir vor, dass der Breakpoint einen bestehenden Befehl
> überschreibt. Wie wird der ursprüngliche Befehl dann beim Fortsetzen
> ausgeführt?

Ein SW Breakpoint im Flash wird nicht zurückgeschrieben sondern 
simuliert vom Jlink.
Jedenfalls kommt beim steppen duurch Flash SW Breakpoints kein 
aufblitzen des Programmierbalkens vom Jlink und es geht auch richtig fix 
drüber.

Den break wieder durch den vorherigen Befehl zu ersetzen gibts aber 
auch.
Der Debugger macht das was grade am sinnvollsten ist.

Jim M. schrieb:
> Die mit Breakpoints überschriebenen Befehle
> werden "simuliert",d.h. deren Seiteneffekte direkt vom Debugger in die
> Hardware geschrieben.

Ich kann aber mitten im Debuggen den Spannung ausschalten und den 
Debugger abstöpseln, nach einem Neustart läuft das Binary auf dem 
Cotroller ohne jede Beeinträchtigung.

... schrieb:
> Kann ein RTOS weiterlaufen beim Debuggen?
> Oder werden alle Timerinterrupts beim Debuggen abgewuergt?
> Kann der J-Link auf wundersame Weise HW-Register auslesen
> ohne das das Auslesen bereits Zustaende der Hardware
> veraendert?

Und mit welchem Debugger arbeitest Du der das obige alles beherrscht, 
inklusive der wundersamen lesen-ohne-zu-lesen-Funktion? Wieviel kostet 
der?

@Bernd:
Ja welche CPU denn?
Läuft die ausm Flash oder RAM?
Waren kleiner/gleich Breakpoints gesetzt als die CPU Hardwarebreakpoints 
hat?

Mw E. schrieb:
> @Bernd:
> Ja welche CPU denn?
> Läuft die ausm Flash oder RAM?

Aus dem Flash, RAM wäre gar nicht genug drin bei den kleinen die ich 
benutze.

> Waren kleiner/gleich Breakpoints gesetzt als die CPU Hardwarebreakpoints
> hat?

Eine handvoll. Ehrlich gesagt hab ich noch nicht nachgezählt und mit dem 
Datenblatt verglichen. Mir ist halt noch nie aufgefallen daß nach nem 
Power-Cycle noch irgendwelche Breakpoints aktiv waren oder daß der 
J-Link sonst jemals was mit dem Controller gemacht hätte was nicht durch 
Aus/Einschalten wieder weggegangen wäre.

Ich werd das aber sobald ich wieder an meinem Arbeitsplatz sitze gleich 
mal explizit testen: Mehr Breakpoints setzen als die CPU kann, dann hart 
abstöpseln, Debugger beenden, anstöpseln und das komplette Flash 
auslesen und vergleichen.

OK, ihr habt recht.

Manchmal(!) patcht er das Flash. Aber nicht immer, und auch nicht immer 
sofort wenn ich den Breakpoint setze sondern irgendwann beim 
Durchsteppen! Und ich sehe ständig Meldungen durchrauschen daß er auch 
Breakpoints entfernt wenn ich von Breakpoint zu Breakpoint springe.

Im obigen Fall habe ich laut IDE insgesamt 21 Breakpoints gesetzt aber 
er hat nur an 3 Stellen ein bkpt #0 eingefügt.

@Bernd
Ab und zu brauchts eben mal eine Gegenprobe um die Theorie zu bestätigen 
;)

Demnächst wirds für mich auch ernst einen GDB Server zu proggen, der den 
MIPS TTL Rechner debuggen kann.
Für den eigenbau MIPS Emulator mit der Emulation der MIPS TTL Rechner 
Peripherie gibts ja schon einen GDB Server.
Aber der hat natürlich unendlich "Hardware" Breakpoints.

Da der MIPS1 Befehlssatz bereits einen break Befehl hat wird der auch 
genutzt.
Ich weis nur noch nicht ob ich den Befehl dann simuliere oder das break 
ersetze gegen den Original Befehl und drauf springe.
(Der MUL/DIV Befehl ist da doch eher speziell)
Am FPGA Nachbau läuft zumindest schonmal das CPU Anhalten und der 
Singlestep Betrieb mit dem Auslesen aller wichtigen Register.

Was nur etwas nervt ist, dass der GDB immer alle Breakpoints gelöscht 
haben will, weil die Verbindung könnte abbrechen.
Da würde ich gerne mal wissen wie der Jlink damit umgeht (es gibt ja nen 
GDB Server fürn JLink).
Immer alle Breakpoints ausm Flash löschen tut er ja nicht wenn die CPU 
angehalten wurde.
Warscheinlich eine kleine "Heuristik":
Wenn breakpoint erwischt und CPU gestoppt und dann mehrere Breakpoints 
auf einmal gelöscht werden sollen, dann diese gesetzt lassen.
Erst wenn beim weiterlaufen ein Breakpoint fehlt, dann wirklich löschen 
oder wenn nur einer gelöscht werden soll.
? Ich habe keine Ahnung, aber so würd ichs wohl machen.


Im weiteren Verlauf muss der GDB Server Eigenbau dann auch noch OS aware 
werden, aua. (eigenbau OS)