remote debug

[martin_frb]

Per mail von mschnell

Wie wäre es, wenn man statt der gdb->gdbserver - Verbindung eine (TCP/IP-) Kommunikation zwischen der Lazarus IDE (mittels einer neuen "remotedebugger"-Klasse) und einem neuen mit Lazarus geschriebenen Oberflächen-losen "Debugserver" Programm macht. Dabei würde das "Debugserver" Programm die normale (nicht remote) gdb-koppel Klasse und damit den normalen gdb des Zielsystems verwenden.

Man würde also "nur" das komplette Interface zwischen der gdb-Klasse und der IDE über einen TCP/IP-Stream remoten. Es wäre also nur ganz normaler Pascal-Code zu bauen. Auf Besonderheiten des gdb braucht dabei keine Rücksicht genommen zu werden.

Wenn die gdb-Klasse selber ein User-Interface hat, muss es natürlich über derselben Stream remoteted werden, die Klasse sollte dazu zunächst in eine Oberflächen-lose "Business-Logik" und eine "GUI"-Klasse aufgeteilt werden, ohne dass sich die Funktion in irgendeiner Weise ändert. Das Interface kann dann gestreamt werden.

Damit sollte es doch möglich sein, die komplette Funktionalität zu erhalten und auf dem Zielsystem ist es nicht notwendig, einen gdbserver zur Verfügung zu stellen.

Können wir ja 'mal im Forum (welchem auch immer) diskutieren.

Wenn jemand das schreiben will...

Die GDB Server Klasse zu fixen ist wesentlich weniger Arbeit und zudem ggf auch fuer normale GDB nuetzlich.

GDB kennt (in gdb Server, und auf einigen, aber nicht allen Plattformen auch im gdb) einen async mode

Anstatt von "r" (run) kann man "r &" senden. Dann kann man waehrend die app laueft "interuupt" senden, um die app zu pausieren. Derzeit muss man ausserhalb von GDB ein Signal senden. (Und das geht nur local)


Einen eigenen GDB server (selbst wenn auf Lazarus Features reduziert) zu schreiben ist sehr viel aufwendiger.

[mschnell]

Wie debugt man denn die Funktion der Debugger Klasse in Lazarus ?

Geht das überhaupt ?

-Michael

[martin_frb]

Wie alles andere.

Man oeffnet "ide/lazarus.lpi" in der IDE. F9 startet dann ein 2tes lazarus, das im debugger laeuft. Und in dem 2ten Lazarus startet man dann ein weiteres projekt.... (2 Monitore sind zu empfehlen)

Ausserdem gibt es jede Menge debugln (installiere LazIdeLogger, und Du kannst die gezielt und zur Laufzeit ein/ausschalten.)

Es gibt auch einen testcase. (Bevor man den ausfuehrt MUSS man die IDE frisch kompilieren. Sonst gibt es ggf Chaos / ppu im falschen ordner)

[mschnell]

Hört sich ja erstmal machbar an.

Danke !

-Michael

[mse]

Anstatt von "r" (run) kann man "r &" senden. Dann kann man waehrend die app laueft "interuupt" senden, um die app zu pausieren. Derzeit muss man ausserhalb von GDB ein Signal senden. (Und das geht nur local)

In MSEide sende ich an gdb sigint falls gdb mit einem gdbserver verbunden und nicht im async Modus ist.
Ich benutze MSEide häufig zum Entwickeln von embedded Applikationen mit Energy Micro EFM32, wobei MSEide mittels gdb->gdbserver->Segger-J-Link-debug-interface mit dem Chip kommuniziert. Auch das flashen geht über diesen Weg. Funktioniert ausgezeichnet. Ganz ähnlich funktioniert es mit Atmel AVR32, womit ich ebenfalls schon grössere Projekte gemacht habe.
Die Einstellungen für EFM32 sind dann z.B. so:

Martin

[af0815]

Funktioniert eigentlich in Lazarus das Remote Debugging mittels gdb->gdbserver. Ich bin dabei es zu testen, kann aber Lazarus nur auf gdb mittels SSH umnstellen.

Debian wheezy
Lazarus 1.1 SVN 40119
FPC 2.7.1 SVN 23560

Händisch reagiert der remote. Ich kann ein Programm im gdb remote am Target starten und laufen lassen. Host ist Debian X86, Target ist arm

[mschnell]

Hört sich gut an.

Wenn mseIDE remote debuggen per gdb kann, müsste man es der Lazarus IDE ja auch beibringen können.

Wenn ich Dích recht verstehe ist der "sigint" Trick nötig, damit man ein unter gdb laufendes Programm anhalten und dann z.B. weiter single-steppen kann.

Lazarus sendet, wenn ich das richtig verstanden habe in diesem Fall ein sigint an die Applikation, was natürlich bei gdb->gdbserver nicht möglich ist.

Anscheinend geht sigint an den lokalen gdb wohl immer.

Damit ist der erste Bugfix für das Lazarus "GDB-Objekt" ja bereits in der Mache

-Michael

[mschnell]

Händisch reagiert der remote. Ich kann ein Programm im gdb remote am Target starten und laufen lassen. Host ist Debian X86, Target ist arm

Damit wäre die Grundvoraussetzung bereits geschaffen. Ich habe auch schonmal ein bisschen mit der gdb Kommandozeile gespielt. Wenn Du gdb mit "gdb --tui" startest, ist das auch ganz brauchbar zu bedienen.
-Michael

[af0815]

Funktioniert eigentlich in Lazarus das Remote Debugging mittels gdb->gdbserver.

Wer lesen kann, ist klar im Vorteil Habe es gefunden.

Im Thread Re: Remote Debugger (Windows -> Linux)

Code: Alles auswählen

To be able to select it in the IDE, add the new unit GDBMIServerDebugger tu the uses clause of ide\debugmanager.pas
 

Eingetragen, neu kompiliert und schon hat man die Einstellungen. Mal testen.

Edit:
Mit F8 durchs Programm steppen geht, die Antwortzeit ist zwar bei ca. 3 Sekunden aber es geht. Breakpoint funktioniert auch.

[mschnell]

Einen eigenen GDB server (selbst wenn auf Lazarus Features reduziert) zu schreiben ist sehr viel aufwendiger.

Da hast Du mich vielleicht missverstanden. Ich will nicht das gdb -> gdbserver - Interface benutzen, sondern dem Pascal-Object, das das Interface zum gdb ein Steaming-Interface zu dem aufrufenden Objekt geben. (dazu könnte man möglicherweise das vorhandene Objekt auch in zwei Objekte aufteilen. ) Also eine reine Pascal-Typische Kommunikations-Aufgabe, hat mit gdb selbst eigentlich wenig zu tun.

Noch einfacher wäre vielleicht die in- und out- (ASCII) Streams, mit denen Lazarus den gdb steuert über TCP/IP zu leiten und den normalen gdb auf dem Target laufen zu lassen. Das müsste doch eigentlich (bis auf das "Stoppen von Hand") ohne viel Programmieren gehen. Nachteil: gdb ist natürlich viel "dicker" als gdbserver.

-Michael

[mschnell]

Die GDB Server Klasse zu fixen ist wesentlich weniger Arbeit und zudem ggf auch fuer normale GDB nuetzlich.

Bevor ich mich jetzt in den Sourcen verirre: Was ist denn die "GDB-Server-Klasse" ?

Ich habe im fpc-Forum erfahren, dass Lazarus zum Debuggen grundsätzlich den Kommandozeilen-gdb aufruft (also das Executable mit stdin und stdout Stream steuert), während fp aus der gdb-Library einzelne Funktionen einbindet.

Wenn das gdb executable gesteuert wird, ist es doch fast egal, ob es sich um gdb zu,m lokalen Gebrauch handelt oder um eine gdb->gdbserver - Kombi.

Der Unterschied ist natürlich möglicherweise das "Stoppen von Hand". Aber hier kann man laut mse ja in beiden Fällen ein Signal an den (lokalen) gdb schicken.

-Michael

[mschnell]

Mit F8 durchs Programm steppen geht, die Antwortzeit ist zwar bei ca. 3 Sekunden aber es geht. Breakpoint funktioniert auch.

Super !
(Ich freue mich schon auf Deine "Mitschrift" zum Cross-Compilieren und Remote Debuggen Ich übersetze sie dann gerne ins Englische.)

Dann kannst Du ja den mse-Trick einbauen damit auch das Stoppen von Hand geht.

Was ist sonst noch zu tun ?

-Michael

[martin_frb]

af0815 hat es richtig erkannt.

Und mit dem Tip von mse sollte (sobald umgesetzt) alles funktionieren.
Und das beste. Das sollte sogar ganz einfach umzusetzen sein...


Spaeter mehr

[mse]

Das sollte sogar ganz einfach umzusetzen sein...

Mit gdb und debuggern im Allgemeinen ist nichts "ganz einfach"...

Martin

[martin_frb]

Das sollte sogar ganz einfach umzusetzen sein...

Mit gdb und debuggern im Allgemeinen ist nichts "ganz einfach"...

Martin

Wie wahr, wie wahr...