Re: [Cgdb-devel] compile for cygwin

[Bob R. <bob...@co...>]

On Tue, Mar 18, 2003 at 08:14:41AM -0500, Peter Kovacs wrote:
> The main developer is on vacation at the moment, although he might get a
> chance to check his mail.  I know that in the past we had problems
> running under cygwin because cgdb creates a pseudo-tty in order to talk
> to gdb.  This should be removed in CVS, however the CVS version is a
> little unstable at the moment. =20
>=20
> - Peter
>=20
> On Tue, Mar 18, 2003 at 01:56:14PM +0100, Armin Diehl wrote:
> > Hi,
> >=20
> > I'm tying to compile for cygwin, the compile runs fine but the resultin=
g=20
> > cgdb.exe will core dump:

hmmm, I have had bad luck trying to support cygwin. I find that I can
get cgdb to work find for win NT, 2000 and then I run it on XP and it
doesn't work ( just an example ). I am not sure why your configuration=20
is core dumping. I do use cgdb almost daily on cygwin at work on a
windows 2000 and windows NT box.

> >=20
> > $ gdb-old --args ./cgdb -d /bin/gdb-old.exe
> > GNU gdb 2003-03-03-cvs (cygwin-special)
> > Copyright 2003 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and yo=
u are
> > welcome to change it and/or distribute copies of it under certain=20
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for deta=
ils.
> > This GDB was configured as "i686-pc-cygwin"...
> > (gdb) r
> > Starting program: /usr/src/cgdb-0.2.3/src/cgdb.exe -d /bin/gdb-old.exe
> >=20
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x610c540a in wmemset () from /usr/bin/cygwin1.dll
> > (gdb) bt
> > #0  0x610c540a in wmemset () from /usr/bin/cygwin1.dll
> > #1  0x610b3409 in fputs () from /usr/bin/cygwin1.dll
> > #2  0x0040dfed in io_debug_write_fmt (fmt=3D0x4100dc "[%s]") at io.c:74
> > #3  0x00410434 in tgdb_init_forkAndExecPty (debugger=3D0x22ff01=20
> > "/bin/gdb-old.exe", argc=3D0, argv=3D0x100
> > 50d2c, slavename=3D0x41a9c0 "", masterfd=3D0x414718, need_nl_mapping=3D=
0) at=20
> > tgdb_init.c:95
> > #4  0x0040b120 in tgdb_init (debugger=3D0x22ff01 "/bin/gdb-old.exe",=20
> > argc=3D0, argv=3D0x10050d2c, gdb=3D0x41
> > 41f0, child=3D0x4141f4) at tgdb.c:95
> > #5  0x00402d81 in start_gdb (argc=3D0, argv=3D0x10050d2c) at cgdb.c:226
> > #6  0x0040383b in main (argc=3D0, argv=3D0x10050d2c) at cgdb.c:539
> > (gdb)

I will try to reproduce this when I get back home with the latest update
of cygwin. Are you using a non-standard gdb? ( I noticed gdb-old.exe ).
One funny thing you might try is to name the debugger you are starting just
gdb.exe or gdb ( That may or may not be a bug on my part :) ).

What compiler are you using to compile cgdb?
What OS are you running?

> >=20
> > This happens with the 0.2.3 version. I also tried the cvs version, it=
=20
> > will not core dump but will print nonsense in the upper half of the=20
> > screen and hangs after that.

cgdb 0.2.3 is the most stable. However, the cgdb team has had trouble
changing cgdb because of its design. So, an effort to redesign several
core components is underway in cvs. Unfortunately it is not ready yet. I
hope to have it done by the end of the first week in April. After that,
we will be testing it. If all goes well, then cgdb 0.3.0 will be
released.

This is the best I can offer.

Thanks,
Bob Rossi