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