gdbserver starten, wie?

[DualCoreCpu]

Hallo,

ich habe im Internet vom gdbserver gelesen und würde den gerne ausprobieren. Vielleicht lässt sich ja ein passender Client bauen.

So sieht mein Kommandozeile aus:

gdbserver 127.0.0.1:1520

Danach Strg+Alt+Entf gedrückt und im Taskmanager unter Prozesse geguckt. Kein gdbserver und auch keine gdb.exe zu sehen in der Liste der aktiven Prozesse.

Muss ich zwingend ein Programm zum Debuggen mitgeben?

Oder wie muss die korrekte Kommandozeile aussehen?

Mit TCP/IP müsste doch dem Server egal sein, wo der Rechner steht, der den Server aufruft und wo sich letztlich das zu debuggende Programm befindet.

Mein Rechner ist zwar für LAN konfiguriert, aber ich weiß auch, das die IP:127.0.0.1 den lokalen Rechner kennzeichnet. Auf dem liegt mein gdbserver und meine zu debuggende .exe

Habe soeben der obigen Kommandozeile noch mein zu debuggendes Programm mit Pfad angegeben, in der Schreibweise, wie auch sonst auf der Kommandozeile des lokalen Rechners üblich, also:

lw:/Verzeichnis/myprog.exe

Nun ist die Console geöffnet und ich erhalte die Meldung "litening port 1520". Aber ich kann keine Debugkommandos eingeben. Was muss ich also anders machen.

Kann mir jemand mal ein Aufrufbeispiel geben oder mir eine einsteigerfreundliche verständliche Dokumentation nennen oder verlinken?

Oder muss ich nun von einem anderen Programm, das TCP IP beherrscht, auf den Port zugreifen, um mit dem Debugger kommunizieren zu können.

Wenn ich mit einem anderen Programm per TCP/IP auf den Server zugreifen muss, bleibt dann die IP Adresse weiterhin die mit dem Aufruf von gdbserver mitgegebene, auch wenn das zugreifende Programm auf einem anderen Rechner läge. Im Netz wären ja sonst zwei IP Adressen nötig, die des Rechners mit dem gdbserver und die des entfernten Rechners, der dessen Dienste anfordert. Oder wie würde das im Netz aussehen, wenn zum Beispiel der gdbserver auf der Compilerfarm von Sourceforge läge und mein zu debuggendes Programm auf meinem PC?

[sx2008]

Wenn du möchtest, dass der Server sowohl vom gleichen Rechner als auch von anderen Rechnern aus erreichbar ist, dann muss die IP-Adresse so aussehen:

Code:

0.0.0.0:1520

Wenn du 127.0.0.1:1520 (=localhost:1520) verwendest, kannst du nicht von anderen Rechnern auf den Server zugreifen.

[mse1]

Zitat:

Zitat von DualCoreCpu

Kann mir jemand mal ein Aufrufbeispiel geben oder mir eine einsteigerfreundliche verständliche Dokumentation nennen oder verlinken?

Das debuggen mittels gdbserver geschieht durch gdb. gdb stellt die Kommunikation zum gdbserver her.
Folgendes gilt für Zielsystem = lokales System auf Linux, target = consoleprog, für Windows sinngemäss:

Zuerst gdbserver in einem termial auf dem Zielsystem starten:

Zitat:

mse@linuxca:~/proj/msegui/testcase/mse/console> gdbserver localhost:4242 ./consoleprog
Process ./consoleprog created; pid = 9867
Listening on port 4242

In einem 2. Terminal auf dem lokalen System gdb starten, Verbindung zu target herstellen ("target remote"), target-Programm starten ("c" für continue):

Zitat:

mse@linuxca:~/proj/msegui/testcase/mse/console> gdb ./consoleprog
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mse/proj/msegui/testcase/mse/console/consoleprog...done.
(gdb) target remote localhost:4242
Remote debugging using localhost:4242
_FPC_PROC_START () at si_prc.inc:49
49 si_prc.inc: Datei oder Verzeichnis nicht gefunden.
in si_prc.inc
(gdb) c
Continuing.

Nun kann im target-Terminal mit dem Programm gearbeitet werden, debugging geschieht im lokalen Terminal.
Target:

Zitat:

Remote debugging from host 127.0.0.1
*Hello World*, program started.
q
Q
Program finished.

Child exited with status 0
GDBserver exiting
mse@linuxca:~/proj/msegui/testcase/mse/console>

Lokal:

Zitat:

Program exited normally.
(gdb)

Meist lässt sich die gdbserver Einstellung in der IDE vornehmen beispielsweise für MSEide und xterm auf target-System:

http://homepage.bluewin.ch/msegui/pics/remotedebug1.png
Und so sieht es dann aus:

http://homepage.bluewin.ch/msegui/pics/remotedebug2.png
gdb Dokumentation:
http://sourceware.org/gdb/current/onlinedocs/gdb/
gdbserver remote Protokoll:
http://sourceware.org/gdb/current/on...emote-Protocol

Martin

[DualCoreCpu]

Hallo,

Danke erst mal für die schnelle Antwort. Ich habe jetzt die beiden folgenden Kommandozeilen nacheinander eingegeben.

gdbserver 0.0.0.0:1520 D:/Programme/lazarus/debugger/test/examples/testcntr.exe

gdb D:/Programme/lazarus/debugger/test/examples/testcntr.exe

Nun vermisse ich aber im gdb-Bildschirm diese beiden Zeilen:

(gdb) target remote localhost:4242
Remote debugging using localhost:4242

Wie also muss ich meine Kommandozeile ändern. Ich will ja den gdb über den Port ansteuern können.

Denn, wenn ich gdb nach Serverstaert so hier aufrufe:

gdb target remote localhost:4242

D:/Programme/lazarus/mingw/bin\remote: No such file or directory

Wie also garantiere ich jetzt, das ich gdb wirklich über den Port bediene und nicht per gdb Console?

Hab die IP gleich mal angepasst. Wie aber ist das, wenn ich von einem Client aus sowohl einen GDB auf meinem lokalen Rechner als auch einen GDB auf einem entfernten Rechner im Netzwerk aufrufen eill? Muss ich dann auch die IP Adresse 0.0.0.0 verwenden, wenn der gdbserver auf meinem lokalen Rechner ist, der GDB aber auf dem entfernten Rechner.

Oder hab ich hier einen Denkfehler, weil davon auszugehen ist, das wenn ich einen gdb auf dem entfernten Rechner aufrufen will, auch den gdbserver auf demselben entfernten Rechner aufrufen muss.
Ich geh mal davon aus, das auf der Sourceforge Compilerfarm irgendwo ein GDB ist. Nun ist es aber, wie ich soeben erfahre, zeitraubend, erst mal die richtige Kommandozeile zu finden für einen korrekten Aufruf. Wenn mir das gelungen ist, will ich mir einen wie auch immer aufgebauten Client bauen, der diese Kommandozeile immer so aufruft, wie ich sie mir derzeit erarbeite. Damit will ich dann sowohl mein lokales gedserver/gdb Gespann als auch ein solches Gespann auf einem Netzwerkrechner aufrufen können, zunächst mal mit der Annahme, das das zu debuggende Programm auf dem Rechner liegt, wo auch der Debugger ist.

Zitat:

Zitat von mse1

Meist lässt sich die gdbserver Einstellung in der IDE vornehmen beispielsweise für MSEide und xterm auf target-System:

Darf ich wissen, in welcher Unit der Aufruf (die Sntax der Kommandozeilen) verstckt ist? Habe mir die mseide-Quellen runter geladen. Da könnte ich statt hier zu experimentieren, auch in der Quelle nachschauen.

Danke auch für den Link zur gdb Dokumentation. Werd mir die ersst mal durcharbeiten. Aber, um Kommandos zu erlernen, indem ich sie aufrufe und deren Wirkung sehe, muss ich gebserver und gdb erst mal erfolgreich gestartet haben. Will später von einem Client im Netzwerk drauf zugreifen.
Die diesbezüglich interessanten Fragen zur Compilerfarm auf Sourceforge folgen später. Jetzt will ich erst mal das Gespann gdbserver und gdb so aufrufen können, das ich den GDB über Port ansteuern kann, um später den Client bauen zu können.

[mse1]

Zitat:

Zitat von DualCoreCpu

Nun vermisse ich aber im gdb-Bildschirm diese beiden Zeilen:

(gdb) target remote localhost:4242
Remote debugging using localhost:4242

Nach dem gdb-prompt "(gdb)" musst du "target remote <deine gdbadresse und port> <enter>" eingeben.

Zitat:

Darf ich wissen, in welcher Unit der Aufruf (die Sntax der Kommandozeilen) verstckt ist? Habe mir die mseide-Quellen runter geladen. Da könnte ich statt hier zu experimentieren, auch in der Quelle nachschauen.

Die Kommunikation mit gdb ist in tgdbmi aus unit lib/common/designutils/gdbutils.pas gekapselt.
Das Starten der debug-Umgebung passiert in apps/ide/main.pas, tmainfo.loadexec().

Martin

[mse1]

Zitat:

Zitat von DualCoreCpu

Oder hab ich hier einen Denkfehler, weil davon auszugehen ist, das wenn ich einen gdb auf dem entfernten Rechner aufrufen will, auch den gdbserver auf demselben entfernten Rechner aufrufen muss.

gdb läuft in der Regel auf dem lokalen Rechner, lediglich gdbserver läuft auf dem entfernten target-Rechner.

Zitat:

Ich geh mal davon aus, das auf der Sourceforge Compilerfarm irgendwo ein GDB ist. Nun ist es aber, wie ich soeben erfahre, zeitraubend, erst mal die richtige Kommandozeile zu finden für einen korrekten Aufruf. Wenn mir das gelungen ist, will ich mir einen wie auch immer aufgebauten Client bauen, der diese Kommandozeile immer so aufruft, wie ich sie mir derzeit erarbeite.

Oder benutze die entsprechenden Einstellungen deiner IDE, siehe meine Beispiel-screenshots.

[DualCoreCpu]

Hallo,

Danke, wie verrückt. Habe das Kommando target remote <meine-IP>:<mein-Port> auf dem gdb Bilschirm eingegeben und habe die folgende Rückmeldung vom GDB:

Remote debugging using <meine-IP>:<mein-Port>
Switching to thread <Nummer>
<Hex-Adresse> in ?? ()
(gdb)

Damit hoffe ich mal, mein Ziel erreicht zu haben. Wie aber mach ich das komplett von der Kommandozeile aus? Auf dem lokalen Rechner kann ich meinen GDB ja noch aufrufen, um dort die ergänzenden Kommandos einzugeben. Aber auf dem entfernten Rechner?

Ich brauche also einen gdb Aufruf von der Kommandozeile aus, wie den hier:

gdb target remote localhost:4242

vorhin hatte ich da aber diese Fehlermeldung im GDB Bildschirm.

D:/Programme/lazarus/mingw/bin\remote: No such file or directory


Wenn ich dagegen das gleiche Kommando im GDB Bildschirm eingebe klappt es. Ich möchte aber das Gleiche von der Kommandozeile aus erreichen.
Später von einem Client aus will ich ja auch auf GDB zugreifen.

Ooooder kann ich im Netzwerk auch den GDB erst mal starten und dann vom Client aus über TCP/IP zB. mit einem mittels Indy Komponente idTCPClient über den Port das GDB Kommando nachreichen, das ihm sagt, von welchem Port die folgenden Kommandos kommen? Kann ich mir aber nicht so recht vorstellen.
Wenn ich über den Port per TCP/IP Client auf den gdbserver zugreife, vorausgesetzt, gdb wurde vorher auch gestartet, aber gdb weiß noch nicht, von welchem Port aus die folgenden Kommandos kommen?

Ich setze dabei voraus, das der gdbserver und der gdb, egal von wo angesteuert, sich immer im selben Verzeichnis auf demselben Rechner befinden. Dann könnte ja der gdbserver den gdb finden und könnte das Kommando übergeben. Ist das so auch korrekt? Dann müsste ich jetzt ne kleine Clientanwendung bauen und damit weiter experimentieren.

[DualCoreCpu]

[quote="mse1"]gdb läuft in der Regel auf dem lokalen Rechner, lediglich gdbserver läuft auf dem entfernten target-Rechner.
[quote]
Ok, aber mein Problem ist, den GDB von der Kommandozeile aus so zu steuern, das ich ihm Kommandos geben kann und die Ausgabe aud meiner Konsole erhalte.

Vom Client aus GDB Kommando geben

GDB gibt seine ERgebnisausgaben auf die Konsole

Client liest dieese Ausgaben und bereitet sie so auf, das ich mit der erhaltenen Debuginfo wie:

-Name der aktuell bearbeiteten Funktion
-Name der aktuell bearbeiteten Quellcodedatei
-Zeilennummer in dieser Quellcodedatei

weiter arbeiten kann. So wie das eine IDE auch macht.

Ich mag zwar die Kommandozeile ganz und gar nicht, aber es gibt Situationen, in denen ein Programmaufruf über eine solche gemacht werden muss. :gruebel:

Ok, GDB ist also in der Regel auf dem lokalen Rechner, aber der nimmt nicht alle Kommandos von der Konsole, sondern eineige müssen vom GDB Bildschirm aus gegeben werden und die Ausgaben gehen nicht auf die Konsole, sondern auf den GDB Bildschierm.

Deswegen interessiert mich der gdbserver, in der Hoffnung, das ich dann den gdb vollständig von der Konsole aus steuern kann und dessen Ausgaben wieder auf die Konsole erhalte, egal ob über TTY oder Port. Denn wenn ich mischon die Arbeit mache, einen eigenen Client zu bauen, soll der so flexibel, wie möglich sein. :wink:

[mse1]

Zitat:

Zitat von DualCoreCpu

Damit hoffe ich mal, mein Ziel erreicht zu haben. Wie aber mach ich das komplett von der Kommandozeile aus? Auf dem lokalen Rechner kann ich meinen GDB ja noch aufrufen, um dort die ergänzenden Kommandos einzugeben. Aber auf dem entfernten Rechner?

gdb läuft in der Regel auf dem lokalen Rechner und kommuniziert z.B. mittels TCP/IP mit gdbserver auf dem entfernten Rechner. Falls gdb auf dem entfernten Rechener läuft, braucht es keinen gdbserver, dafür eine Terminal-Verbindung mit dem entfernten Rechner, beispielsweise SSH. Ich weiss aber nicht, ob SuseBuildService diese Möglichkeiten bietet.
Ich würde mal auf der Mailingliste fragen, falls die BuildService Dokumentation darüber keine Auskunft gibt.

Zitat:

Ich brauche also einen gdb Aufruf von der Kommandozeile aus, wie den hier:

gdb target remote localhost:4242

gdb kann ein start script angegeben werden mit der option -x oder mit der option -ex ein einzelnes Komando:
http://sourceware.org/gdb/current/on...l#File-Options
also z.B.

Zitat:

gdb -ex "target remote localhost:4242" testprog

Zitat:

Ooooder...

Ich verstehe nicht ganz was du schlussendlich erreichen willst?

[mse1]

Zitat:

Zitat von DualCoreCpu

Client liest dieese Ausgaben und bereitet sie so auf, das ich mit der erhaltenen Debuginfo wie:

-Name der aktuell bearbeiteten Funktion
-Name der aktuell bearbeiteten Quellcodedatei
-Zeilennummer in dieser Quellcodedatei

weiter arbeiten kann. So wie das eine IDE auch macht.

Da musst du gdb über pipes betreiben.

Zitat:

Ok, GDB ist also in der Regel auf dem lokalen Rechner, aber der nimmt nicht alle Kommandos von der Konsole, sondern eineige müssen vom GDB Bildschirm aus gegeben werden und die Ausgaben gehen nicht auf die Konsole, sondern auf den GDB Bildschierm.

Deswegen interessiert mich der gdbserver, in der Hoffnung, das ich dann den gdb vollständig von der Konsole aus steuern kann und dessen Ausgaben wieder auf die Konsole erhalte, egal ob über TTY oder Port.

Der "GDB Bildschirm" ist die Konsole.

[sx2008]

Ob man einen Webserver betreiben möchte oder den gdbserver oder einen sonstigen Server; bei TCP/IP gibt es im Prinzip drei mögliche IP-Adressen, auf denen der Server lauschen kann:
1.) localhost
Wenn ein Server auf localhost (127.0.0.1) lauscht, dann kann man ihn nur über das Loopback-Interface erreichen.
Loopback-Interface bedeutet, es findet kein Datenverkehr über eine Netzwerkkarte statt, sondern die Verbindung läuft intern über Winsock.
Das bedeutet auch, dass der Server nicht von einem anderen Rechner erreichbar ist.
Über das Loopback-Interface können je nach CPU-Power Übertragungsgeschwindigkeiten jenseits von 10 GBit/s erreicht werden.
2.) die eigene IP-Adresse
Lauscht der Server auf der eigenen IP-Adresse, dann kann er über die Netzwerkarte erreicht werden.
Allerdings kann ein Client, der auf dem gleichen Rechner wie der Server liegt nicht das Loopback-Interface verwenden.
Das schränkt die Datenrate unnötigerweise ein.
Ausserdem kann sich der Client nicht mit Localhost verbinden, sondern er muss ebenfalls die eigene IP-Adresse angeben.
3.) 0.0.0.0
Bindet ein Server an die IP-Adresse 0.0.0.0 kann er Verbindungen sowohl über die Netzwerkart(en) als auch über das interne Loopback-Interface annehmen.
Ist der Rechner in mehreren lokalen Netzen zuhause; hat also mehrere IP-Adressen, dann reagiert der Server auf jede dieser IP-Adressen.

[DualCoreCpu]

Zitat:

Zitat von mse1

Die Kommunikation mit gdb ist in tgdbmi aus unit lib/common/designutils/gdbutils.pas gekapselt.
Das Starten der debug-Umgebung passiert in apps/ide/main.pas, tmainfo.loadexec().

Danke für diese Auskunft! Muss ich mir zunächst ganz in Ruhe anschauen, die Quellen studieren und verstehen. So möchte ich eine Auskunft haben. So kann ich das konkrete Verzeichnis aufsuchen wo die angegebene Unit liegt und in dieser die genannte Methode suchen und den Quelltext studieren. Leider ist dort aber nur der Aufruf des GDB Interfaces implementiert. Muss also den Quelltext erst mal in Ruhe studieren. So einen Client brauche ich später.

Zitat:

gdb -ex "target remote localhost:4242" testprog

Das war das noch fehlende Teil im "Puzzle". :hello:

Ich hatte diese Zeile vorher ohne -ex Option und das target remote... Kommando nicht in Anführungszeichen gesetzt.

Jetzt kann dich den GDB mit Portunterstützung starten, wie ich ich es haben wollte. Habe mir die Kurzdoku von dem Sourceware-Link als Textdatei in mein gdb Verzeichnis kopiert, um später da nachlesen zu können.

Zitat:

Ich verstehe nicht ganz was du schlussendlich erreichen willst?

Ich will den GDB als Debugserver verwenden. Egal ob mit oder ohne gdbserver. Will einen Debugclient bauen, wie Kdbg einer ist. Kdbg läuft aber nach meinem Wissen nur unter Linux. Ich will ihn aber für Windows haben.

Wozu aber hierzu einen eigenen Debugger schreiben, wenn es doch dafür GDB gibt. Der braucht nur seine Debuginfos an meinen Client weiterleiten, wo sie passend angezeigt wird.

Werde aber in meiner mseide die Debuggereinstellungen wie im Screenshot angegeben übernehmen, falls nicht schon eingestellt, damit der GDB auch mit dieser IDE funzt.

Zitat:

gdb läuft in der Regel auf dem lokalen Rechner und kommuniziert z.B. mittels TCP/IP mit gdbserver auf dem entfernten Rechner. Falls gdb auf dem entfernten Rechener läuft, braucht es keinen gdbserver, dafür eine Terminal-Verbindung mit dem entfernten Rechner, beispielsweise SSH. Ich weiss aber nicht, ob SuseBuildService diese Möglichkeiten bietet. Ich würde mal auf der Mailingliste fragen, falls die BuildService Dokumentation darüber keine Auskunft gibt.

So zu sagen gibt es also viele Möglichkeiten, den GDB von einem entfernten Programm aus anzusteuern. Ich habe mich für die TCP/IP Variante entschieden, weil die auf allen Plattformen verfügbar ist. Und weil mit den Indy Komponenten, die es sowohl für Linux als auch für Windows und hier sowohl für Delphi als auch für Freepascal gibt, eine portable Schnittsetelle zum GDB herstellbar ist.

@sx2008:
Danke auch Dir für die ausführliche Erklärung:

Die Bedeutung der verschiedenen IP Adressen ist eine wichtige Information für mein Vorhaben!

Jetzt bin ich aber dran:
Werde nun erst mal die GDB Doku studieren und auch mit der Indy Komponente IdTCPClient rumspielen.
Dann werd ich schauen, welche Kommunikationsvariante ich auswähle. :coder2:




Danke Euch nochmals für die bereitwillige, zielführende Hilfe. :cheers:

.

[mse1]

Zitat:

Zitat von DualCoreCpu

Ich will den GDB als Debugserver verwenden. Egal ob mit oder ohne gdbserver. Will einen Debugclient bauen, wie Kdbg einer ist. Kdbg läuft aber nach meinem Wissen nur unter Linux. Ich will ihn aber für Windows haben.

Dafür gibt es doch MSEide und Lazarus? Die machen genau das: ein Plattform-unabhängiges graphisches Interface zu gdb...

Zitat:

Zitat von DualCoreCpu

Werde aber in meiner mseide die Debuggereinstellungen wie im Screenshot angegeben übernehmen, falls nicht schon eingestellt, damit der GDB auch mit dieser IDE funzt.

Diese Einstellung braucht es nur für remote debugging. MSEide und auch Lazarus arbeiten normalerweise mit gdb ohne gdbserver.