Debuggen einer Konsolenanwendung

[mse]

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 ?

Dann habe ich das falsch verstanden. Ich meinte, die IDE startet xterm und gdb und gibt gdb beispielsweise das von xterm verwendete Pseudoterminal an. Falls xterm gdb startet stellt sich das Problem, wie die IDE mit gdb kommuniziert.

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 ?

Du hast recht, dies sollte funktionieren. Beispiel xterm session:

Code: Alles auswählen

mse@linuxca:~/proj/msegui/testcase/mse/console> gdbserver localhost:4242 ./consoleprog
Process ./consoleprog created; pid = 6675
Listening on port 4242
Remote debugging from host 127.0.0.1
Program started.
aaaaa
AAAAA
q
Q
Program finished.
 
Child exited with status 0
GDBserver exiting

Und im gdb terminal:

Code: Alles auswählen

mse@linuxca:~/proj/msegui/testcase/mse/console> gdb ./consoleprog
GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
Copyright (C) 2008 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://bugs.opensuse.org/>...
(gdb) target remote localhost:4242
Remote debugging using localhost:4242
_FPC_PROC_START () at si_prc.inc:49
49      si_prc.inc: No such file or directory.
        in si_prc.inc
(gdb) c
Continuing.
 
Program exited normally.
(gdb)

Aber es müsste doch eine einfachere Lösung geben?

gcc mit MSEide geht das ?

Sicher, MSEide ist nicht auf FPC beschränkt sondern bietet allgemeine Edit- Kompilier- und Debug-Unterstützung.

warum nicht ARM, den könnte man mit FPC programmieren.

Weil sich der AVR32 für unsere Anwendungen ausgezeichnet eignet. Betriebssysteme und alle Treiber sind sowieso in C...

MSEide kann doch bestimmt cross-compilieren und remote debuggen....

Sicher, das benötigen wir für den AVR32 ja auch.

Martin

[mschnell]

Falls xterm gdb startet stellt sich das Problem, wie die IDE mit gdb kommuniziert.

Da hast Du natürlich recht. So geht das wohl nicht

Aber es müsste doch eine einfachere Lösung geben?

Vermutlich nicht . Find' ich aber eigentlich gar nicht schlecht. Wie Kylix das damals gemacht hat, weiß ich nicht.

Sicher, MSEide ist nicht auf FPC beschränkt sondern bietet allgemeine Edit- Kompilier- und Debug-Unterstützung.

Super !. Ich muss mich in einer ruhigen Minute unbedingt 'mal wieder mit MSEgui beschäftigen ....

Weil sich der AVR32 für unsere Anwendungen ausgezeichnet eignet. Betriebssysteme und alle Treiber sind sowieso in C...

Und Du hast immer noch nicht den FPC für AVR32 protiert .... (Ich plane irgendwann den FPC für NIOS zu portieren. Vielleicht können wir da zusammenarbeiten NIOS ist sehr ähnlich wir MIPS, hat also 32 General-Purpose-Regisater und keine Flag-Register. Wie funktioniert AVR32 ?

-Michael

[mse]

Hier die Einstellungen falls nicht das eingebaute Konsolenfenster sondern xterm verwendet werden soll:

Und so siehts dann aus:

NIOS ist sehr ähnlich wir MIPS, hat also 32 General-Purpose-Regisater und keine Flag-Register. Wie funktioniert AVR32 ?

RISC mit R0..R12, SP, LR, PC und SR.
http://www.atmel.com/products/avr32/default.asp

[mschnell]

RISC mit R0..R12, SP, LR, PC und SR.

OK er hat also ein Status-Register, ist also (was die Portierung von FPC betrifft) einem ARM ähnlicher als einem MIPS.

Da sollten durchaus überschaubare Änderungen den ARM-Compiler zu einem AVR-Compiler machen.

-Michael