Writing a GDB frontend, help wanted

[Salvador Eduardo Tropea]

Hi All!

I'm the author of SETEdit (http://setedit.sf.net/), maintainer of a 
Turbo Vision port (http://tvision.sf.net/) and co-author of RHIDE 
(http://www.rhide.com/).
SETEdit version 0.5.4 (currently available as Release Candidate 1) have 
support for CygWin (you can compile it using CygWin).
This version of the standalone editor includes a new feature: you can 
use it as a gdb frontend.
This feature is new and we currently know it works for Linux systems.
The current CVS code compiles using a fresh copy of Cygwin (downloaded 
on september 16).
Most of the functionality needed to work as a front-end for gdb seems to 
be in-place, but my tests under Windows 98 SE shown some critical problems.
I personally don't use CygWin, the only thing I do with Cygwin is to 
check if Turbo Vision and SETEdit can be compiled with it.
For this reason I don't have a big motivation on solving Cygwin specific 
detail. That's why I'm looking for people interested on helping to solve 
them.
The binary I compiled can start a debug session (forking and calling 
gdb). The communication with gdb works quite well (much slower than 
Linux, but usable). I added Cygwin specific code to instruct gdb to 
start the program you are debugging using a new terminal (set 
new-console on). The console is created, but its behavior is quite 
bizarre. That's strange because if I use gdb from the bash prompt the 
new terminal seems to behave much better. When I debug a simple "Hello 
world" program the output of the program doesn't go to the new console. 
When I debug a Turbo Vision application it can draw to the new console, 
but input isn't working (no keyboard, no mouse).
I think it could be related to the fact that the current console is in a 
very particular state (needed by Turbo Vision), but I don't know much 
about how is that implemented nor the low level details of Cygwin.
My impression is that the problem is some small detail in the way 
Cygwin's gdb creates the new console and the fix isn't really complex.
If this issue can be solved the Cygwin users could have a gdb frontend 
that doesn't need X emulation and that have a user interface that's 
quite similar to the old Turbo C IDEs. (Note: The editor also supports X ;-)
Note that this approach is completly different to what RHIDE does. RHIDE 
have gdb inside and SETEdit "talks" to gdb using a pipe. One nice 
advantage of this is that you can debug remote applications (RHIDE can't).
If anyone is interested on helping with this please contact me.

Download information:
Turbo Vision CVS snapshot: http://tvision.sourceforge.net/snap.html
SETEdit CVS snapshot: http://setedit.sourceforge.net/snap.html
GDB interface library: 
http://prdownloads.sourceforge.net/libmigdb/libmigdb-0.8.7.tar.bz2?download

SET

-- 
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set@computer.org set@ieee.org 
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/