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

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.

[mse1]

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