gdb Socket Error

[DualCoreCpu]

Hallo,

ich experimentiere grad mit dem gdb/gdbserver Gespann. Dabei erhalte ich einen Socket Error, sobald ich mich mit dem gdb Debugger verbinden will.

Was muss ich da anders machen?

Ist möglicherweise der aktuelle gdb fehlerhaft?
(wenn ja, gibt es da einen workaround?)

Ich habe mir die Beispielprogramme von Einsteigertutorial: Indy 10 nutzen runter geladen und an Stelle des dortigen Servers den gdbserver für die Kommunikation verwendet. Ohne gdb kommt die Clientnachricht beim Server korrekt an. Wenn ich aber nun den GDB mit aufrufe und danach die Clientnachricht sende, kommt der Socket Fehler.

gdb ohne gdbserver aufrufen klappt auch nicht, denn dann meldet gdb, das er keine Verbindung herstellen konnte, während gemeinsam mit gdbserver die Verbindung hergestellt wird.

Das Beispielprogramm aus dem Tutorial stellt auf "ButtonClick" die Verbindung her, sendet dann die Nachricht und unterbricht dann die Verbindung wieder. Habe ich nur den gdbServer gestartet, lässt sich dieses Szenario ständig wiederholen. Verbindung aufbauen, Nachricht senden, Verbindung trennen, immer wieder.

Aber sobald GDB auch aktiv ist, kommt der Socket Fehler.

Muss ich vielleicht ein spezielles Kommando vom Client aus senden, um den Socket Error nicht mehr zu erhalten und stattdessen mit dem gdb kommunizieren zu können?

Gibt der GDB dann seine Ausgaben auch über den vereinbarten Port aus, von wo sie der Client engegen nehmen könnte?

[mse1]

Zitat von DualCoreCpu:

gdb ohne gdbserver aufrufen klappt auch nicht, denn dann meldet gdb, das er keine Verbindung herstellen konnte, während gemeinsam mit gdbserver die Verbindung hergestellt wird.

Ohne gdbserver - das heisst target Programm und gdb laufen auf dem selben Rechner - musst du das "target remote" Kommando weglassen.

Zitat:

Gibt der GDB dann seine Ausgaben auch über den vereinbarten Port aus, von wo sie der Client engegen nehmen könnte?

Die Kommunikation mit gdb geschieht via StdIn, StdOut und pipes, siehe auch
http://www.delphipraxis.net/internal...t.php?t=173578

[DualCoreCpu]

Zitat von mse1:

Zitat von DualCoreCpu:

gdb ohne gdbserver aufrufen klappt auch nicht, denn dann meldet gdb, das er keine Verbindung herstellen konnte, während gemeinsam mit gdbserver die Verbindung hergestellt wird.

Ohne gdbserver - das heisst target Programm und gdb laufen auf dem selben Rechner - musst du das "target remote" Kommando weglassen.

Zitat:

Gibt der GDB dann seine Ausgaben auch über den vereinbarten Port aus, von wo sie der Client engegen nehmen könnte?

Die Kommunikation mit gdb geschieht via StdIn, StdOut und pipes, siehe auch
http://www.delphipraxis.net/internal...t.php?t=173578

Und wie portabel ist das über pipes oder Terminal?

Ich weiß, das die Kommandosyntax in Linux sich von der in Windows unterscheidet.

gdb -ex "target remote /dev/con"

wie in der gdb Doku gefunden, funzt unter Windows nicht!

Per Netzwerk hätte ich eine Kommunikationsschnittstelle, die unabhängig von der Kommandosyntax auf dem System Plattformunabhängig ist. gdbserver aufrufen, gdb starten und per TCP/IP die Kommandos geben und die Ausgabe des GDB entgegen nehmen.

Pipes sind gut und schön. Aber Freepascal bietet in der Unit Pipes nur anonyme Pipes an. Unter Windows brauche ich Named Pipes, um im Duplexbetrieb mit dem Server zu kommunizieren, was ja bei der Kommunikation mit GDB nötig sein dürfte, weil ja der GDB nach Erhalt eines Kommados Ergebnisse liefert, die ich auswerten muss, wenn ich von einem Cliet aus mit GDB kommuniziere.

Deshalb favorisiere ich TCP/IP Zugriff. Der ist wegen des Internet auf allen Plattformen verfügbar.

Wenn ich somit später, wenn alles läuft, denke:

"Schön, jetzt kann ich diesen meinen Client nutzen, um den GDB auf der Sourceforge Compilerfarm anzusprechen, sollte es mir somit egal sein, auf welchem Betriebssystem der Server läuft. AUf einer Compilerfarm, wie der von Sourceforge dürfte ja der gdbserver+gdb bereits aktiv sein, womit ich den gdbserver mit den in der gdb Doku angegebenen Debugger Kommandos korrekt ansprechen dürfte. Denn die GDB Kommandos haben sowohl auf Windows als auch auf Linux als auch auf ... dieselbe Syntax, was meine Programmentwurf ungemein vereinfachen dürfte.

[quote="mse1"]
Ohne gdbserver - das heisst target Programm und gdb laufen auf dem selben Rechner - musst du das "target remote" Kommando weglassen.
[quote]
Hmmmm! Wie sieht denn dann die korrekte Kommandozeile aus?

Ich will den GDB über TCP/IP ansprechen.
Ich will vom Client aus den GDB starten und dann über TCP/IP mit dem GDB kommunizieren.
Dabei soll der GDB vom Cliet die Debug Kommandos erhalten und zunächst seine komplette AUsgabe, die sonst auf das Kommando im GDB Bilschierm folgt, an meinen Client senden. Dort werte ich dann die Ausgabe aus.

Wie also sieht da die korrekte Kommandozeile aus?

Muss ich auf dem lokalen Rechner dazu den gdbserver gestartet haben, damit die TCP/IP Kommunikation klappt, oder genügt der GDB alleine? Mein Client befindet sich, wie der GDB auf dem lokalen Rechner.

Momentan sind Client und GDB noch in verschiedenen Verzeichnissen. In der Finalversion meines Clients sollen Client und GDB im selben Verzeichnis liegen.

Die MSEIde ist klasse, aber lass auch mich einen Beitrag leisten. Ich brauche die korrekte Kommandozeile, um den GDB per Netzwerk anzusprechen und ihm von einem Client aus Kommandos zu geben, deren Ergebnis dann der Client weiter verwendet. Wenn also dazu der gdbserver auch auf dem lokalen Rechner zwingend mit gestartet werden muss, meine Reihenfolge: 1. gdbserver, 2. gdb, dann muss ich eben den gdbserver zuerst starten. Aber wie übergebe ich nach Start von gdbserver und gdb die gdb Kommandos so, das ich den Socket Error nicht erhalte?

Habe soeben mal den gdbserver mit der Hostadresse 0.0.0.0 statt 127.0.0.1 aufgerufen.
Beim Cliet habe ich sowohl mit IP:0.0.0.0 als auch mit 127.0.0.1 experimentiert.

Egal, oder der Server mit IP:0.0.0.0 oder 127.0.0.1 gestartet wird, der gdb will 127.0.0.1 , die 0.0.0.0 akzeptiert er auch dann nicht, wenn der gdbserver mit dieser IP gestartet ist.

Ich erhalte auf jeden Fall den Socketfehler EIdSocketError mit der Meldung:

Client mit IP:0.0.0.0 Server mit IP:0.0.0.0
Cannot assign requested address

Client mit IP:127.0.0.1 Server mit IP:0.0.0.0
Connection refused

Client mit IP:127.0.0.1 Server mit IP:127.0.0.1
Connection refused

Client mit IP:0.0.0.0 Server mit IP:127.0.0.1
Cannot assign requested address

Es sollte doch irgendeine Möglichkeit geben, den GDB im Netzwerk anzusprechen. Warum ist das so kompliziert? Geht das nicht einfacher zu implementieren???

Der Client ist mit Indy 10 -> IdTCPClient realisiert:

ConnectTimeout = 0
ReadTimeOut = -1
IPVersion = Id_IPv4

[mse1]

Zitat von DualCoreCpu:

Und wie portabel ist das über pipes oder Terminal?
...

Na, langsam habe ich das Gefühl in der Delphi-PRAXIS wird man manchmal etwas verarscht. Vermutlich liegt es an der Fasnachts/Faschingszeit?

gdb ist ein Konsolen Programm. Unter Linux (UNIX) erben Kind-Prozesse die filehandle input, output und erroroutput (0,1 und 2). Bei Windows gibt es einen ähnlichen Mechanismus mit startupinfo.hstdinput,hstdoutput,hstderror und startf_usestdhandles bei createprocess().
Die Kommunikation zwischen deinem Kgdb-Ersatz (parent-process) und gdb (child-process) geschieht nun über die filehandle stdinput und stdoutput, die Verbinung stellen pipes her. In MSEide geschieht dies in der procedure tgdbmi.startgdb() aus lib/common/designutils/gdbutils.pas. MSEgui hat zur Bedienung der pipes die Komponenten tpipreader und tpipewriter. FPC hat TProcess für diesen Zweck.

Zitat:

Ich weiß, das die Kommandosyntax in Linux sich von der in Windows unterscheidet.

gdb -ex "target remote /dev/con"

wie in der gdb Doku gefunden, funzt unter Windows nicht!

Klar, Windows hat ja auch kein /dev/con ...

Zitat:

Per Netzwerk hätte ich eine Kommunikationsschnittstelle, die unabhängig von der Kommandosyntax auf dem System Plattformunabhängig ist. gdbserver aufrufen, gdb starten und per TCP/IP die Kommandos geben und die Ausgabe des GDB entgegen nehmen.

Dein Programm startet gdb als Kindprozess und kommuniziert mittels stdinput und stdoutput, siehe oben...

Zitat:

Es sollte doch irgendeine Möglichkeit geben, den GDB im Netzwerk anzusprechen. Warum ist das so kompliziert? Geht das nicht einfacher zu implementieren???

Der lokale gdb kommuniziert mit dem entfernten gdbserver übers Netzwerk, nicht dein Kgdb-Ersatz mit gdb. Aber auch das haben wir ja schon besprochen...

Martin