remote debug

[af0815]

Das Problem ist, das es nur ein Login gibt für 'admin'. Auf einer Entwicklungsmaschine nicht wirklich ein Securityissue.

Ich kannte bisher auch nicht die Möglichkeit des SSH-GDB Debuging und die Lösung mit GDB-GDBServer erscheint mir auch schlüssig. Damit ist ja nicht einmal ein SSH notwendig, sondern es geht direkt über die Ports.

Pragmatische Lösung: Wenn beide Versionen gehen, so kann man nehmen was dem persöhnlichen Geschmack trifft bzw. gerade erforderlich ist.

Edit:
Weil ich das ganze auch ein wenig Dokumentieren will und mit einem testsystem arbeite - Die FPC Version spielt hier keine Rolle, ich kann also auch den aktuellen sStable (2.6.0) nehmen. Für das debuggen ist ja Lazarus zuständig, deshalb muß ich dort den aktuellen trunk nehmen.
Warum, ich habe die Tests bisher auf FPC trunk und Lazarus trunk gemacht, will die Anleitung aber soweit wie möglich ist auf den aktuellen Stable basieren lassen.

Ist es aus eurer Sicht also notwendig, FPC stable und Lazarus trunk zu nehmen, oder geht FPC stable und Lazarus stable auch ?

Zusatzfrage: Welche gdb Version ist derzeit möglich und getestet.

[mschnell]

Das Problem ist, das es nur ein Login gibt für 'admin'. Auf einer Entwicklungsmaschine nicht wirklich ein Securityissue.

Ich finde, auf einem "embedded" Zielsystem ist es sinnvoll und unproblematisch ein login als "admin" zu machen. (Warum heißt das bei QNAP eigentlich "admin" und nicht "root" ???)

Ich habe gerade ausprobiert, dass das nicht erzwingt, dass man am PC als root angemeldet ist: "ssh admin@ip_adresse" (und dann Passwort-Abfrage) geht von der Kommandozeile eines normalen Users auf dem Linux-PC (und bei einem normalen Windows-User geht login mit Putty).

Ist es aus eurer Sicht also notwendig, FPC stable und Lazarus trunk zu nehmen, oder geht FPC stable und Lazarus stable auch ?

Da für ssh ja Lazarus übersetzt werden muss, um die auskommentierten Login-Zeilen zu aktivieren (nachdem sie unter Umständen weiterentwickelt worden sind) würde ich mit der trunk Version arbeiten.

-Michael

[martin_frb]

SO ich habe mal mit new asyncgdb mode angefangen.

Unter Windows funktioniert der gdbserver damit (allerdings ist der alte Signal to PID Code auch noch da, wird aber normalerweise nicht verwandt).

Unter Linux hab ich noch nicht getestet.

[af0815]

Ich nehme an, bei normalen gdb Einsatz oder betrifft das auch gdb over Ssh. Oder nur das ?

Bin momentan dabei mein Crosscompiling , crossdebugging Anleitung rein zu schreiben und nochmals zu überprüfen. Dort arbeite ich aber im ersten Ansatz mit gdb/gdbserver zwischen i386/Debian wheezy und Arm/Qnap 212. Werde aber gdb over ssh auch testen.

Der erste Run hat ja recht gut funktioniert, dazu gibts aber einen eigenen Thread.

[martin_frb]

Ich nehme an, bei normalen gdb Einsatz oder betrifft das auch gdb over Ssh. Oder nur das ?

Nug "over ssh" und "gdbserver"

Der normale Debugger verwendet nach wie vor, den nicht async mode. Es gibt eine neue Property fuer die Optionen. Die ist aber nicht published (not yet). Einfach die Aus-Kommentierung entfernen.

ssh und gdb erver benutzten beide den neuen Mode: WENN GDB das untertuetzt. Sonst den alten. Und es gibt keine Warnung, wenn der alte verwandt wird.

[af0815]

ssh und gdb erver benutzten beide den neuen Mode: WENN GDB das untertuetzt.

Nachdem ich den gdb selbst kompiliere, auf was muß ich da achten, das der 'aktzeptiert' wird. Sprich welche Eigenschaft wird vom GDB abgefragt um die Entscheidung zu treffen.

[martin_frb]

set target-async on
show target-async

-exec-next &


Das $ ist aber nicht erforderlich, da GDB das im MI mode nicht immer existiert, allerdings anscheinend auch ohne & im background ausfuehrt.

[mschnell]

Andy und Martin:

Ich verstehe im Moment leider nur Bahnhof, was schade ist, weil mein Ziel ja die Verwendung des "normalen" gdb auf dem Target via SSH ist (also ohne gdbserver) und ich gerne davbe mitmachen würde, das zu ermöglichen.

Fragen:
- reicht da eine vorhanden (ältere/nicht mit allen optionen ausgestattete) Version des GDB auf der Zielplattform oder muss man zur Verwendung (via SSH) mit Lazarus extra einen bauen, der entsprechende Spezifikationen erfüllt ?

- Welche Spezifikationen sind das ?

- muss man (falls man den gdb bauen muss) wirklich cross-compilieren, oder reicht der "normale" gcc auf dem Zielsystem um den gdb - Sourcecode zu übersetzen ?

- Was muss an Lazarus erweitert werden, damit das Debuggen remote via SSH geht (den "auskommentierten Code" habe ich mir angesehen).

Wie weit seid Ihr damit ?

-Michael

[martin_frb]

Man muss NICHT selber bauen.

Die Unterstuetzung von "async" haengt allerdings von der Plattform ab, auf der GDB laueft, aber selber kompilieren aendert das nicht.

Sprich: Wenn GDB (aktuelle Version)) es fuer dein System nicht kann, dann war es das. Da gibt es kein fix, kein workaround.


DIe IDE *SOLL* erkennen, wenn es nicht unterstuetzt wird, und automatisch den alten Mode benutzen. ABER noch nicht umfassend getestet

Siehe WIKI.Im alten Mode funktioniert nicht alles.


Wenn die "pause" taste im GDB ueber SSH funktioniert, nutzt er den neuen Modus.

[martin_frb]

Im normalen Mode nimmt GDB keine Eingaben an, waehrend die app laueft.

Die IDE muss um die app zu pausieren ein Signal senden. Das geht nur, wenn die app auf dem selben Rechner wie die IDE laeuft.
(Ja man koennte ein remote IDE tool schreiben. Hat aber noch keine. Und ich habe es nicht vor)


Im async mode, nimmt GDB Eingaben an. Man kann "interrupt" als Wort/Kommando an den GDB sendene Und GDB sorgt fuer die pause.

Allerdings sind die GDB rueckmeldungen anders. Deshalb musste die IDE angepasst werden.

Und gdb kann das nicht auf allen platformen

[mschnell]

Dann sollten wir erstmal sicherstellen, das der gdb auf unseren Systemen ("ARMEL v4" oder so) async kann...

Wenn nicht, wäre eine mögliche Alternative zu gdbserver ein eigener Deamon, der über einen TCP-IP Port von Lazrus den Befehl bekommt, ein Signal an das Programm unter Debug zu schicken....

Ist zwar eine etwas krumme Methodik, lässt sich aber komplett in Pascal machen.

-Michael

[martin_frb]

oder gdbserver.

Auf Windows z.B. kann GDB es nicht. Aber gdbserver kann es.

Und GDBserver Unterstuetzung ist im Prinzip vollstaendig da. Einfach unit in uses einfuegen

[mschnell]

Und GDBserver Unterstuetzung ist im Prinzip vollstaendig da. Einfach unit in uses einfuegen

Bei Lazarus schon, aber auf dem Zielsystem ?????

Andy musste dafür (er hat ein ähnliches Zielsystem wie ich) gdbserver für das Zielsystem und gdb selbst (für den Entwicklungs-Rechner) aus den gnu Sourcen übersetzen weil (1) für die Ziel-Platform kein gdbserver zu finden war und (2) der gdb, der an gdbserver andocken soll, aus denselben Sourcen (Version) übersetzt werden muss wie gdbserver. Er hat das geschafft, aber wenn wir eine Wiki-Seite einrichten wollen um die Remote-Debug - Möglichkeiten für andere User zugänglich zu machen, sollten wir eine Variante wählen, die einfacher an's Laufen zu bringen ist.

Außerdem hat er geschrieben, dass die gdb/gdbserver-Verbindung bei ihm sehr langsam ist (mehrere Sekunden Verzögerungen). Da hoffe ich, dass die Fernsteuerung von gdb via SSH keine zusätzliche Verzögerung bewirkt.

-Michael

[af0815]

set target-async on
show target-async

Habe ich beim jetzigen gdb/gdbserver nicht. Allerdings habe ich absichtlich nicht den aktuellsten GDB genommen.

Ich nehme an, das ist erst bei den letzten gdb Versionen machbar. Nur kann ich für Lazarus (trunk) die aktuellste Version nehmen ?

[martin_frb]

Die IDE sollte mit allen GDB Versionen laufen (unter Windows habe ich 6.3 bis 7.5 getestet)

Info zum async (alles was ich hab):
http://www.sourceware.org/gdb/onlinedoc ... ution.html
http://sourceware.org/gdb/onlinedocs/gd ... modes.html

Eine liste welche targets das nun koennen hab ich nicht gefunden.