Einzelnen Beitrag anzeigen

DualCoreCpu
(Gast)

n/a Beiträge
 
#3

Re: gdb Socket Error

  Alt 16. Feb 2010, 13:09
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
  Mit Zitat antworten Zitat