Debuggen einer Konsolenanwendung

[c-bob]

Die Frage ist mglw. zu simpel, aber wie kann man ein Konsolenprogramm unter Linux debuggen? Also mit Brechpunkten arbeiten usw.?
Beispiel: wenn ich auf eine Eingabe warte und diese auswerten will oder wenn ich das Programm in einer Schleife habe, welche auf Ereignisse wartet, dann kann ich das entsprechende Programm zwar aus der IDE heraus starten, aber es wird dadurch ja keine Konsole geöffnet, wie z.B. unter Windows.

Grüße
_c_

[Hitman]

Start --> Startparamater --> Startprogramm verwenden [x] --> das Feld mit dem Befehl entsprechend anpassen --> starten

[c-bob]

Danke Hitman! Ich denke, das wird das sein, was ich gesucht habe - kann es bis jetzt aber nicht nutzen, weil immer eine Fehlermeldung kommt, die besagt, das xterm entweder fehlt oder nicht ausführbar ist. HAb dazu baer nix gefunden.

Hat jemand ne Idee?

[Socke]

Ich hätte dazu noch eine sehr unqualifizierte Meinung:
Das Lazarus-Programm wird gar nicht durch Lazarus bzw. den Debugger gestartet sondern durch das Terminal und ist somit auch nicht debuggbar. Wenn xterm aber nicht da ist (kann auch vorkommen) brauchst du einen anderen Terminalemulator bspw. gnome-terminal unter GNOME.

[c-bob]

@Socke, ja nach weiterem hinschauen ist mir das (debugproblem) auch aufgefallen. Kann es leider aber immernoch nicht testen, da ich aus der IDE heraus immernoch nicht starten kann (mit obigem Dialog). Dabei ist alles vorhanden, Wenn ich nämlich selbigen dort angemeckerten command-string in der console ausfürhe, dann klappt das

[Hitman]

Du wirst wahrscheinlich den gesamten Pfad zur Anwendung nehmen müssen. In der Konsole wird normalerweise eine nicht auffindbare Executable in $PATH gesucht und dann ausgeführt ... das muss nicht unbedingt auch gelten, wenn der Prozess anderweitig gestartet wird.

[marcov]

Normaler wise tut man das (unter Delphi und GDB beide) mit ein Debugger attach am schon hochgefahrenes Prozess.

Ich weiss nicht ob Lazarus dieser GDB moeglichkeit sichtbar macht, aber GDB hat sie bestimmt.

[mse]

Die Frage ist mglw. zu simpel, aber wie kann man ein Konsolenprogramm unter Linux debuggen?

MSEide hat sowohl unter Linux als auch unter Windows ein einfaches internes Konsolenfenster. Auch attach process ist möglich.
Nicht vertiggebracht habe ich bis heute die bequeme Verwendung eines externen Terminalprogrammes unter Linux, für allfällige Hinweise wäre ich dankbar.

Martin

[c-bob]

@Hitman, okay, das geht jetzt. Zumindest der Start aus Lazarus heraus.
Das Problem des Debuggens besteht aber leider weiterhin. Den Debugger kann man so nicht direkt benutzen.

@markov, kannst Du da etwas mehr dazu sagen? Vielleicht kann man das ja auch unter Lazarus realisieren. Kenne mich mit dem gdb noch nicht wirklich aus. Vielleicht kann man das ja auch über die Startparameter realisieren.

@mse, was meinst du mit "externem Terminalprogramm"? Meinst Du speziell auf MSEide bezogen?

[monta]

Du solltest xterm installieren. Es ist teilweise ohnehin sehr tief in Lazarus verankert, das xterm vorhanden und vorausgesetzt ist. Und xterm steht ja für jede Linux-Distribution zur Verfügung.

[mse]

@mse, was meinst du mit "externem Terminalprogramm"? Meinst Du speziell auf MSEide bezogen?

Wie gesagt hat MSEide ein einfaches internes Konsolenfenster. Damit können Konsolen Programme mit voller Debuggerunterstützung gestartet werden. Dieses Konsolenfenster ist aber keine Terminalemulation und kennt keine Farbeinstellungs- und Cursorsteuerungscodes. Wie man beispielsweise xterm startet, das eigene Programm in gdb laufen lässt und dann stdout, stdin und stderr des Prüflings mit xterm verbindet habe ich noch nicht herausgefunden. Man kann xterm beauftragen ein Programm zu starten aber wie bringt man xterm dazu beispielsweise ein bestehendes, mit der Anwendung verbundenes Pseudoterminal zu bedienen?

[mschnell]

Ich kann mir nicht vorstellen dass das geht.

Ich denke die richtige Methode ist (1) Xterm starten und das zu testende Programm starten lassen und dann gdb mit dem Programm verbinden, oder (2) Xterm starten und gdb so starten lassen, dass gdb seinerseits das zu testende Programm läd.

Um bei (2) eine GUI zu verwenden, müsste GDB möglicherweise im Remote-Modus ("gdbserver") gestartet werden und die GUI läd dann den Bedienteil von GDB, der sich dann über TCP/IP mit gdbserver verbindet.

Soweit ich weiß ist es schon gelungen, mit Lazarus remote-debugging (z.B. zu einem ARM-Target) zu machen.

-Michael

[c-bob]

@mschnell:
Kannst Du das näher erklären? Xterm starten, dann in gdb das soeben kompilierte Programm laden und per 'run' laufen lassen? Wie komme ich dann mit den Breakpoints zurecht, die ich in der IDE gesetzt hab? Wie kann ich mir dann Variableninhalte ansehen etc.?

@monta:
xterm ist bereits installiert - der Pfad, der per default in den Startparametern angegeben ist, stimmt nur nicht, das hatte ich übersehen.

-c-

[mse]

Ich kann mir nicht vorstellen dass das geht.

Kylix konnte das.

Ich denke die richtige Methode ist (1) Xterm starten und das zu testende Programm starten lassen und dann gdb mit dem Programm verbinden,

Und wie verhindert man, dass das Programm anläuft bevor es unter gdb Kontrolle steht?

oder (2) Xterm starten und gdb so starten lassen, dass gdb seinerseits das zu testende Programm läd.

Das wäre meine Methode. Nun, wie kriegt man die Verknüpfung der stdios zwischen xterm und Programm hin?

Um bei (2) eine GUI zu verwenden, müsste GDB möglicherweise im Remote-Modus ("gdbserver") gestartet werden und die GUI läd dann den Bedienteil von GDB, der sich dann über TCP/IP mit gdbserver verbindet.

xterm läuft im "Serverraum" oder diesseits des Proxy hinter gdb?

Soweit ich weiß ist es schon gelungen, mit Lazarus remote-debugging (z.B. zu einem ARM-Target) zu machen.

Das mache ich mit MSEide auch täglich mit einem gdb-Proxy um AVR32 zu programmieren, gcc selbstverständlich.

Martin

[mschnell]

Und wie verhindert man, dass das Programm anläuft bevor es unter gdb Kontrolle steht?

Das habe ich mich auch gefragt. Das Problem ist aber nicht spezifisch für Commandline-Programme, sonder generell beim nachträglichen Attachen von gdb. Man muss wohl das Programm so schreiben, dass es zunächst 'mal auf eine Eingabe wartet.

oder (2) Xterm starten und gdb so starten lassen, dass gdb seinerseits das zu testende Programm läd.
Das wäre meine Methode. Nun, wie kriegt man die Verknüpfung der stdios zwischen xterm und Programm hin?

Ich verstehe nicht, warum das ein Problem ist. So wird das doch bei reinem Commandline-debuggen mit gdb auch gemacht. XTerm startet GDB und verbindet die stdios mit GDB, gdb startet das Programm und verbindet die stios mit dem Programm. Was sehe ich da falsch ?

xterm läuft im "Serverraum" oder diesseits des Proxy hinter gdb?

Verstehe ich jetzt nicht. Xterm startet gdbserver, gdbserver startet das zu testende Programm. Unabhängig davon läuft die GUI und verbindet sich über TCP/IP mit gdbserver (u.U. auf demselben Rechner). Sollte das nicht gehen ?

Soweit ich weiß ist es schon gelungen, mit Lazarus remote-debugging (z.B. zu einem ARM-Target) zu machen.
Das mache ich mit MSEide auch täglich mit einem gdb-Proxy um AVR32 zu programmieren, gcc selbstverständlich.

gcc mit MSEide geht das ?
warum nicht ARM, den könnte man mit FPC programmieren. MSEide kann doch bestimmt cross-compilieren und remote debuggen....

-Michael
(ich versuche gerade 'mal wieder meine Kollegen dafür zu interessieren das nogui Application Modell von MSEGUI zu verwenden, um Delphi-Programme auf Controllern ohne Grafikhardware laufen zu lassen...)