cgdb-devel — Development activity -- bug reports, patches, related questions

Re: [Cgdb-devel] compile for cygwin

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

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 resulting=
=20
> cgdb.exe will core dump:
>=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.
>=20

Hi Armin,

I just recently fixed cgdb for cygwin with XP.
You can give it a shot out of cvs if you'd like.
Otherwise, cgdb-0.3.0 will be released probably within April.

Thanks,
Bob Rossi

Re: [Cgdb-devel] cgdb 0.3.0

[Peter K. <pe...@ko...>]

Yeah, I want to finish the config stuff and work on keybindings, but I'm
not sure when I'm going to get a good chunk of free time.  Of course,
we've been working on 0.2.x for several months now.

- Peter

On Fri, Mar 28, 2003 at 08:51:04AM -0500, Bob Rossi wrote:
> On Fri, Mar 28, 2003 at 08:27:02AM -0500, Peter Kovacs wrote:
> > Excellent work Bob.  When are you doing to officially make a release,
> > (and announce on Freshmeat, etc)?
> >=20
> > - Peter
> >=20
> > --=20
> > Peter D. Kovacs <pe...@ko...>
>=20
> I don't know, I figured we could work out of cvs for a few days without
> any major changes. If there are no major bugs, we can release 0.3.0.
>=20
> I know that you and Mike both have cool changes that you plan on doing.
> I figured you'd get those in somewhere in the 0.3.x range.
> Does that sound right?
>=20
> My next major task is going to be to add a testsuite. I am going to look
> into dejagnu. That way we can type 'make check'. I have broken the same
> things over and over and its starting to frustrate me :).
> I'll probably get that into a 0.3.x version.
>=20
> Bobby



--=20
Peter D. Kovacs <pe...@ko...>

Re: [Cgdb-devel] cgdb 0.3.0

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

On Fri, Mar 28, 2003 at 08:27:02AM -0500, Peter Kovacs wrote:
> Excellent work Bob.  When are you doing to officially make a release,
> (and announce on Freshmeat, etc)?
>=20
> - Peter
>=20
> --=20
> Peter D. Kovacs <pe...@ko...>

I don't know, I figured we could work out of cvs for a few days without
any major changes. If there are no major bugs, we can release 0.3.0.

I know that you and Mike both have cool changes that you plan on doing.
I figured you'd get those in somewhere in the 0.3.x range.
Does that sound right?

My next major task is going to be to add a testsuite. I am going to look
into dejagnu. That way we can type 'make check'. I have broken the same
things over and over and its starting to frustrate me :).
I'll probably get that into a 0.3.x version.

Bobby

Re: [Cgdb-devel] cgdb 0.3.0

[Peter K. <pe...@ko...>]

Excellent work Bob.  When are you doing to officially make a release,
(and announce on Freshmeat, etc)?

- Peter

--=20
Peter D. Kovacs <pe...@ko...>

[Cgdb-devel] cgdb 0.3.0

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

Hey guys,

I finished up a lot of work with cgdb lately in an effort to get out
cgdb-0.3.0. I think the work is finally done.

I have re-written the input mechanism to cgdb. Now cgdb uses the input
unit in cgdb/input. I have successfully replaced the call to getch in
cgdb.c with the new input unit. There are still several calls to wgetch
and I will try to phase those out soon.

The benefit to the new input library is:
   1. cgdb no longer depend on the 1 second delay that getch returns for
   curses/ncurses implementations.
   2. cgdb can now bind keys that getch doesn't bind. Such as Alt-A and
   Alt-Shift-A
   3. cgdb can now send all the raw data to gdb and to the child
   program, whereas before it could not send any raw data that was
   returned from curses as a macro KEY_* because there was no way to get
   the key sequences that made up that macro.

I have also re-written the readline interface that cgdb uses. Instead of
depending on gdb's readline, tgdb now uses its own readline. The
readline is behind an interface called rlctx.c. If we needed to, we
could eventually replace that interface with implementation we want, but
for now it just invokes another process dedicated to readline support.
  =20
The benefits to the new readline library is:
   1. tgdb now has control over readline, so it can save the commands
   from the last session, input macros, ...
   2. cgdb can now also have an instance of readline in its status bar.
   This was not possible before.
   3. the new MI interface does not support readline, so this is the
   only way to get that support.

Anyways, just keeping you updated. I think it is safe to say the cvs
tree is now as stable as 0.2.3 and better because of all the bug fixes
and feature enhancements.

Talk to you later,
Bob Rossi

[Cgdb-devel] readline interface

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

Hi,

In an effort to fix the cvs branch, I just committed a fix that finished
up the major effort to integrate the new readline support in tgdb.
In doing so, I added a new program to cgdb/tgdb. It is called
rlctx_prog. It stands for readline context program. In order to make the
cvs tree work now, after doing the ./configure && make, you should do a
make install. Make sure rlctx_prog is in your path. It should be because
cgdb is in your path and they should be installed in the same dir.

Anyways, let me know about bugs. This is a big advance for tgdb.

Thanks,
Bob Rossi

Re: [Cgdb-devel] compile for cygwin

[Peter K. <pe...@ko...>]

After I finish unpacking I should have some time to continue looking at
the config stuff.  I plan on getting key-bindings in there next.

- Peter

On Tue, Mar 18, 2003 at 05:47:17PM -0500, Mike Mueller wrote:
> Yes, I'm planning on doing the config file.  I was going to work on=20
> help first, but it doesn't matter which I do next.  We have another=20
> bug to look at, too.  I'll talk to you when you're back.
>=20
> Mike
>=20
> On Tue, 18 Mar 2003, Bob Rossi wrote:
>=20
> :On Tue, Mar 18, 2003 at 11:16:39PM +0100, Armin Diehl wrote:
> :> Bob,
> :>=20
> :> >What compiler are you using to compile cgdb?
> :> >What OS are you running?
> :>=20
> :> The machine where i compiled and got the segfault was xp, cygwin was=
=20
> :> installed a few days ago.
> :> Compiler is gcc version 3.2 20020927 (prerelease), this is the version=
=20
> :> that was included in the cygwin distribution.
> :>=20
> :> and i forgot: in io.c it dumps core because dfd is null (fprintf(dfd,=
=20
> :> "%s", va_buf);) in io_debug_write
> :
> :Ok, I know what the problem is now. It seems as if cgdb can't create the
> :home directory in XP. I'll have to inspect why cgdb does not die
> :gracefully.
> :
> :> Another short question: Is it possible to automate the :set sc ?
> :
> :Not yet. A planned feature that I think Mike will be working on for the
> :next release is a .cgdbrc file. That will provide you with what you
> :want.
> :
> :Mike or Peter, I know we have talked about it. Did either of you plan on
> :adding that feature for the next release?
> :
> :Thanks for the reports,
> :Bob Rossi
> :
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Does your code think in ink?=20
> You could win a Tablet PC. Get a free Tablet PC hat just for playing.=20
> What are you waiting for?
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel

--=20
Peter D. Kovacs <pe...@ko...>

Re: [Cgdb-devel] compile for cygwin

[Mike M. <mmu...@cs...>]

Yes, I'm planning on doing the config file.  I was going to work on 
help first, but it doesn't matter which I do next.  We have another 
bug to look at, too.  I'll talk to you when you're back.

Mike

On Tue, 18 Mar 2003, Bob Rossi wrote:

:On Tue, Mar 18, 2003 at 11:16:39PM +0100, Armin Diehl wrote:
:> Bob,
:> 
:> >What compiler are you using to compile cgdb?
:> >What OS are you running?
:> 
:> The machine where i compiled and got the segfault was xp, cygwin was 
:> installed a few days ago.
:> Compiler is gcc version 3.2 20020927 (prerelease), this is the version 
:> that was included in the cygwin distribution.
:> 
:> and i forgot: in io.c it dumps core because dfd is null (fprintf(dfd, 
:> "%s", va_buf);) in io_debug_write
:
:Ok, I know what the problem is now. It seems as if cgdb can't create the
:home directory in XP. I'll have to inspect why cgdb does not die
:gracefully.
:
:> Another short question: Is it possible to automate the :set sc ?
:
:Not yet. A planned feature that I think Mike will be working on for the
:next release is a .cgdbrc file. That will provide you with what you
:want.
:
:Mike or Peter, I know we have talked about it. Did either of you plan on
:adding that feature for the next release?
:
:Thanks for the reports,
:Bob Rossi
:

Re: [Cgdb-devel] compile for cygwin

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

On Tue, Mar 18, 2003 at 11:16:39PM +0100, Armin Diehl wrote:
> Bob,
>=20
> >What compiler are you using to compile cgdb?
> >What OS are you running?
>=20
> The machine where i compiled and got the segfault was xp, cygwin was=20
> installed a few days ago.
> Compiler is gcc version 3.2 20020927 (prerelease), this is the version=20
> that was included in the cygwin distribution.
>=20
> and i forgot: in io.c it dumps core because dfd is null (fprintf(dfd,=20
> "%s", va_buf);) in io_debug_write

Ok, I know what the problem is now. It seems as if cgdb can't create the
home directory in XP. I'll have to inspect why cgdb does not die
gracefully.

> Another short question: Is it possible to automate the :set sc ?

Not yet. A planned feature that I think Mike will be working on for the
next release is a .cgdbrc file. That will provide you with what you
want.

Mike or Peter, I know we have talked about it. Did either of you plan on
adding that feature for the next release?

Thanks for the reports,
Bob Rossi

Re: [Cgdb-devel] compile for cygwin

[Armin D. <di...@no...>]

Bob,

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

The machine where i compiled and got the segfault was xp, cygwin was installed 
a few days ago.
Compiler is gcc version 3.2 20020927 (prerelease), this is the version that was 
included in the cygwin distribution.

and i forgot: in io.c it dumps core because dfd is null (fprintf(dfd, "%s", 
va_buf);) in io_debug_write

and gdb-old.exe is the original that was included in cygwin (GNU gdb 
2003-03-03-cvs (cygwin-special))

i also tryed a plain 5.3 and also renamed it to gdb.exe but no difference. (5.3 
works fine on linux)
It is not urgent for me because i can work on linux. (and there cgdb work fine)

Another short question: Is it possible to automate the :set sc ?

Thanks for your help !

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

Re: [Cgdb-devel] compile for cygwin

[Peter K. <pe...@ko...>]

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

- Peter

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 resulting=
=20
> cgdb.exe will core dump:
>=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 you =
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 detail=
s.
> 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=3D0)=
 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)
>=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.

--=20
Peter D. Kovacs <pe...@ko...>

[Cgdb-devel] compile for cygwin

[Armin D. <di...@no...>]

Hi,

i'm tying to compile for cygwin, the compile runs fine but the resulting 
cgdb.exe will core dump:

$ 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 you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
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

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=0x4100dc "[%s]") at io.c:74
#3  0x00410434 in tgdb_init_forkAndExecPty (debugger=0x22ff01 
"/bin/gdb-old.exe", argc=0, argv=0x100
50d2c, slavename=0x41a9c0 "", masterfd=0x414718, need_nl_mapping=0) at 
tgdb_init.c:95
#4  0x0040b120 in tgdb_init (debugger=0x22ff01 "/bin/gdb-old.exe", 
argc=0, argv=0x10050d2c, gdb=0x41
41f0, child=0x4141f4) at tgdb.c:95
#5  0x00402d81 in start_gdb (argc=0, argv=0x10050d2c) at cgdb.c:226
#6  0x0040383b in main (argc=0, argv=0x10050d2c) at cgdb.c:539
(gdb)

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

[Cgdb-devel] cgdb's future

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

Hi all,

I have been thinking a lot about cgdb lately. I have come up with a set
of problems that must be solved correctly before the next release. I
believe once these problems are solved we will have no problem working
on cgdb in the future. These are problems are not easy to solve and
require making design and feature decisions about cgdb.

I would really appreciate it if you guys would sit and think about these
problems. Maybe coming up with alternate solutions I have not though of.

The basic problems are:
1. Getting ESC sequence input
2. Getting readline to work in cgdb
3. Getting multiple readline sessions working in cgdb

1. Getting ESC sequence input

Problem:
cgdb uses getch to get input from the user. This translates all the ESC
sequences simple. This is great when the user is at the 'cgdb window'.
However, when the user is at the 'gdb window' cgdb passes all data to
readline. So, it can no longer call getch() as readline would not be
happy receiving 'KEY_UP' instead of its ESC sequence. It works if we
just let readline read from stdin when we are in 'gdb mode' but cgdb
will never know if the user hit pgup pgdn when they are in that mode.
I don't think this is very good. I think cgdb should always understand
the ESC sequence the user is trying to user.

Proposed Solution:
a. I think instead of re-writing the input library getch(), we should still
use it. However, if the we do find out that the user hit KEY_UP in the
lower window, we look up the ESC sequence in the terminfo/termcap
library and send it to readline. This saves us from rewriting a
substantial amount of non-trivial code.

b. We could write an input library. readline does it and its easy to
extract. It would still take some time though. At least a month.

2. Getting readline to work in cgdb
Problem:
readline doesn't work the way the documentation says it does.
   Function: void rl_callback_read_char (void)
   Whenever an application determines that keyboard input is available,=20
   it should call rl_callback_read_char(), which will read the next=20
   character from the current input source.

This is true. However, it fails to mention that it will read more than=20
1 char. When ^r is typed it tried to read every char up until the '\n'.
So, since there is no more data on readline's input, it blocks.
This causes cgdb to hang.=20

Proposed Solution:
cgdb can no longer use the alternative interface.=20

a. If we let readline read from stdin, instead of its stdin ( pty I create =
).
This will stop the blocking problem. Since when the user types it would
satisfy readline. However, cgdb would no longer know the ESC sequences
the user typed. so pgup and pgdn would no longer work in the bottom
window.

b. We could make cgdb multi-threaded so it wouldn't block. This seems
non-portable and over complicated to me for some reason.

c. We could make an abstraction to readline. This abstraction would
fork-exec a program that we write. This program would basically just be
around for readline support. That way, cgdb wouldn't hang. Look at next
problem that makes this solution desirable to me ( even though it is
grossly inefficient).

3. Getting multiple readline sessions working in cgdb
Problem:=20
cgdb is trying to use more than one readline at a time. It wants to use
a readline at the 'gdb window' and at the 'status bar'. readline does
not support multiple invocations of itself within a single program. We
could almost kludge it but calls to add_history() would affect each
other. When the user is at the status bar and types KEY_UP then they
would get the commands entered at the gdb window.

Solution:

Don't have multiple invocations of readline in one application.

a. Make libtgdb an application instead of a library. It would have its
own readline. This solution would then still make cgdb multi-threaded to
avoid its blocking problem.  ( I really don't like this idea ).

b. Don't let the 'status bar' have readline support. Ever.=20
( I really don't like this idea ).

c. Make the abstraction to readline, where for every instance of a
readline we want we just fork and exec a new program. I really don't
think the over head of this solution would be terrible, considering the
problems cgdb is facing. ( I really don't like this idea :), but I like
it better than the others ).



Anyways, these are major problems. They need to be solved. Any help
would be awesome.

Thanks,
Bob Rossi

Re: [Cgdb-devel] Crash

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

On Thu, Mar 06, 2003 at 08:56:48AM -0500, Peter Kovacs wrote:
> I just updated to this mornings CVS and I got a crash when I try to set
> a break point:
>=20
> #0  0x08051fef in tgdb_append_command (com=3D0xbffff500, new_header=3DBRE=
AKPOINTS_END, buf=3D0x0, buf2=3D0x0, buf3=3D0x0) at ../../tgdb/lib/types.c:=
85
> 85         (*com)[command_cur_size] =3D xmalloc(sizeof(struct Command));
>=20

I reproduced the problem and fixed it.

Thanks,
Bob Rossi

[Cgdb-devel] Crash

[Peter K. <pe...@ko...>]

I just updated to this mornings CVS and I got a crash when I try to set
a break point:

#0  0x08051fef in tgdb_append_command (com=0xbffff500, new_header=BREAKPOINTS_END, buf=0x0, buf2=0x0, buf3=0x0) at ../../tgdb/lib/types.c:85
85         (*com)[command_cur_size] = xmalloc(sizeof(struct Command));

backtrace:

#0  0x08051fef in tgdb_append_command (com=0xbffff500, new_header=BREAKPOINTS_END, buf=0x0, buf2=0x0, buf3=0x0) at ../../tgdb/lib/types.c:85
#1  0x08053df4 in commands_set_state (state=BREAKPOINT_TABLE_END, com=0xbffff528) at ../../tgdb/annotate-two-src/commands.c:153
#2  0x0805530f in handle_breakpoints_table_end (buf=0x8068100 "breakpoints-table-end\r", n=22, com=0xbffff528) at ../../tgdb/annotate-two-src/annotate.c:112
#3  0x0805547a in tgdb_parse_annotation (data=0x8068100 "breakpoints-table-end\r", size=22, com=0xbffff528) at ../../tgdb/annotate-two-src/annotate.c:426
#4  0x080535e4 in a2_handle_data ( data=0xbfff04c4 "\r\n\032\032post-prompt\r\n\r\n\032\032breakpoints-headers\r\n\r\n\032\032field 0\r\nNum \r\n\032\032field 1\r\nType", ' ' <repeats 11 times>, "\r\n\032\032field 2\r\nDisp \r\n\032\032field 3\r\nEnb \r\n\032\032field 4\r\nAddress    \r\n\032\032field 5\r\nWhat\r\n\r\n\032\032breakpoints-table\r\n\r\n\032\032record\r\n"..., size=443, gui_data=0x80af7a8 "", gui_size=4096, com=0xbffff528) at ../../tgdb/annotate-two-src/state_machine.c:111
#5  0x080530d0 in a2_tgdb_recv (buf=0x80af7a8 "", n=4096, com=0xbffff528) at ../../tgdb/annotate-two-src/a2-tgdb.c:285
#6  0x0804a773 in gdb_input () at cgdb.c:449
#7  0x0804aa50 in main_loop () at cgdb.c:554
#8  0x0804ad7d in main (argc=1, argv=0xbffff648) at cgdb.c:677

It seems as though the com structure got screwed up some how.

- Peter

[Cgdb-devel] readline support

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

Hi,

cgdb now uses readline to interface with the user. Can you guys be the
testers with me? I need to make sure all of this new code works. Its a
major re-write.

Tab-completion does not yet work, so keep around your old version.

Even just checking it out and building it would be helpful.


( One cool thing, cgdb no longer sets the TERM environment variable,=20
  so know it can debug itself :) )

Thanks,
Bobby

Re: [Cgdb-devel] cgdb and readline

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

Wow, I must have looked right over that. Thanks Peter! This is exactly
what we need.

Bobby

On Wed, Feb 19, 2003 at 10:21:57PM -0500, Peter Kovacs wrote:
> I was just searching through the readline info pages and I found this
> entry:
>=20
>     Alternate Interface
>     -------------------
>=20
>        An alternate interface is available to plain `readline()'.  Some
>     applications need to interleave keyboard I/O with file, device, or wi=
ndow
>     system I/O, typically by using a main loop to `select()' on various f=
ile
>     descriptors.  To accomodate this need, readline can also be invoked a=
s a
>     `callback' function from an event loop.  There are functions availabl=
e to
>     make this easy.
>=20
>      - Function: void rl_callback_handler_install (const char *prompt,
>             rl_vcpfunc_t *lhandler)
>          Set up the terminal for readline I/O and display the initial exp=
anded
>          value of PROMPT.  Save the value of LHANDLER to use as a functio=
n to
>          call when a complete line of input has been entered.  The functi=
on
>          takes the text of the line as an argument.
>=20
>      - Function: void rl_callback_read_char (void)
>          Whenever an application determines that keyboard input is availa=
ble,
>          it should call `rl_callback_read_char()', which will read the ne=
xt
>          character from the current input source.  If that character comp=
letes
>          the line, `rl_callback_read_char' will invoke the LHANDLER funct=
ion
>          saved by `rl_callback_handler_install' to process the line.  `EO=
F' is
>          indicated by calling LHANDLER with a `NULL' line.
>=20
>      - Function: void rl_callback_handler_remove (void)
>          Restore the terminal to its initial state and remove the line ha=
ndler.
>          This may be called from within a callback as well as independent=
ly.
>=20
> That seems to be exactly what we need doesn't it?  I'm not sure how we
> would integrate this into our main loop, but at least its a good start.
>=20
> - Peter
>=20
> On Wed, Feb 19, 2003 at 10:12:36PM -0500, Bob Rossi wrote:
> > Hey guys,
> >=20
> > Look at this small example. It reads a line at a time and prints it.
> >=20
> >    #include <readline/readline.h>
> >    #include <readline/history.h>
> >    #include <stdlib.h>
> >=20
> >    /* Gets called when the user hits '\t' */
> >    int rl_complete (int ignore, int invoking_key) {
> >        fprintf(stderr, "complete\n");
> >        return 0;
> >    }
> >=20
> >    int main(int argc, char **argv){
> >        static char *line;
> >        while(1) {
> >            line =3D readline("PROMPT:");
> >            fprintf(stderr, "LINE=3D(%s)\n", line);
> >        }
> >        return 0;
> >    }
> >=20
> > I am trying to integrate readline into cgdb and ran into a problem.
> > Readline has a function called 'readline' that gets a line of input from
> > stdin. This is great, however, it is a blocking call ( It reads a whole
> > line and then returns). This is not good, since cgdb should also be able
> > to receive input if the user is in cgdb mode.=20
> >=20
> > For example, the users types 'info sour' and the ESC 'j' ( to go down a=
 line )=20
> > and then 'i' ( to get back into gdb mode ) and then 'e<CR>'.=20
> >=20
> > How would we get readline to give up control? Or feed it a char at a
> > time? I don't know how to resolve this problem.
> >=20
> > By the way, currently cgdb sits in a select loop reading from stdin,
> > gdb's stdout, and the debugged programs stdout (tty). How could we make
> > readline be a part of this?
> >=20
> > Any suggestions?
> >=20
> > Thanks,
> > Bobby
>=20
>=20
>=20
> --=20
> Peter D. Kovacs <pe...@ko...>

Re: [Cgdb-devel] cgdb and readline

[Peter K. <pe...@ko...>]

I was just searching through the readline info pages and I found this
entry:

    Alternate Interface
    -------------------

       An alternate interface is available to plain `readline()'.  Some
    applications need to interleave keyboard I/O with file, device, or wind=
ow
    system I/O, typically by using a main loop to `select()' on various file
    descriptors.  To accomodate this need, readline can also be invoked as a
    `callback' function from an event loop.  There are functions available =
to
    make this easy.

     - Function: void rl_callback_handler_install (const char *prompt,
            rl_vcpfunc_t *lhandler)
         Set up the terminal for readline I/O and display the initial expan=
ded
         value of PROMPT.  Save the value of LHANDLER to use as a function =
to
         call when a complete line of input has been entered.  The function
         takes the text of the line as an argument.

     - Function: void rl_callback_read_char (void)
         Whenever an application determines that keyboard input is availabl=
e,
         it should call `rl_callback_read_char()', which will read the next
         character from the current input source.  If that character comple=
tes
         the line, `rl_callback_read_char' will invoke the LHANDLER function
         saved by `rl_callback_handler_install' to process the line.  `EOF'=
 is
         indicated by calling LHANDLER with a `NULL' line.

     - Function: void rl_callback_handler_remove (void)
         Restore the terminal to its initial state and remove the line hand=
ler.
         This may be called from within a callback as well as independently.

That seems to be exactly what we need doesn't it?  I'm not sure how we
would integrate this into our main loop, but at least its a good start.

- Peter

On Wed, Feb 19, 2003 at 10:12:36PM -0500, Bob Rossi wrote:
> Hey guys,
>=20
> Look at this small example. It reads a line at a time and prints it.
>=20
>    #include <readline/readline.h>
>    #include <readline/history.h>
>    #include <stdlib.h>
>=20
>    /* Gets called when the user hits '\t' */
>    int rl_complete (int ignore, int invoking_key) {
>        fprintf(stderr, "complete\n");
>        return 0;
>    }
>=20
>    int main(int argc, char **argv){
>        static char *line;
>        while(1) {
>            line =3D readline("PROMPT:");
>            fprintf(stderr, "LINE=3D(%s)\n", line);
>        }
>        return 0;
>    }
>=20
> I am trying to integrate readline into cgdb and ran into a problem.
> Readline has a function called 'readline' that gets a line of input from
> stdin. This is great, however, it is a blocking call ( It reads a whole
> line and then returns). This is not good, since cgdb should also be able
> to receive input if the user is in cgdb mode.=20
>=20
> For example, the users types 'info sour' and the ESC 'j' ( to go down a l=
ine )=20
> and then 'i' ( to get back into gdb mode ) and then 'e<CR>'.=20
>=20
> How would we get readline to give up control? Or feed it a char at a
> time? I don't know how to resolve this problem.
>=20
> By the way, currently cgdb sits in a select loop reading from stdin,
> gdb's stdout, and the debugged programs stdout (tty). How could we make
> readline be a part of this?
>=20
> Any suggestions?
>=20
> Thanks,
> Bobby



--=20
Peter D. Kovacs <pe...@ko...>

[Cgdb-devel] cgdb and readline

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

Hey guys,

Look at this small example. It reads a line at a time and prints it.

   #include <readline/readline.h>
   #include <readline/history.h>
   #include <stdlib.h>

   /* Gets called when the user hits '\t' */
   int rl_complete (int ignore, int invoking_key) {
       fprintf(stderr, "complete\n");
       return 0;
   }

   int main(int argc, char **argv){
       static char *line;
       while(1) {
           line =3D readline("PROMPT:");
           fprintf(stderr, "LINE=3D(%s)\n", line);
       }
       return 0;
   }

I am trying to integrate readline into cgdb and ran into a problem.
Readline has a function called 'readline' that gets a line of input from
stdin. This is great, however, it is a blocking call ( It reads a whole
line and then returns). This is not good, since cgdb should also be able
to receive input if the user is in cgdb mode.=20

For example, the users types 'info sour' and the ESC 'j' ( to go down a lin=
e )=20
and then 'i' ( to get back into gdb mode ) and then 'e<CR>'.=20

How would we get readline to give up control? Or feed it a char at a
time? I don't know how to resolve this problem.

By the way, currently cgdb sits in a select loop reading from stdin,
gdb's stdout, and the debugged programs stdout (tty). How could we make
readline be a part of this?

Any suggestions?

Thanks,
Bobby

Re: [Cgdb-devel] ncurses vs curses

[Mike M. <mmu...@cs...>]

I agree... we shouldn't give up on curses until it proves to be too 
difficult to maintain...  Even if some features are absent, I don't 
see a good reason to exclude curses users from using cgdb.

Mike

On Mon, 17 Feb 2003, Peter Kovacs wrote:

:I say we should still try to offer minimal support for curses.  Sure
:throw in all the bells and whistles if you're using ncurses, but perhaps
:at least try to get something usable when using curses?
:
:- Peter
:
:On Mon, Feb 17, 2003 at 07:02:11PM -0500, Bob Rossi wrote:
:> Hi guys,
:> 
:> I recieved this bug report today via Email.
:> 
:> The only ( minor ) thing that bothers me is that my xterms have a white
:> background by default, while cgdb use a black one, and, halas, do not 
:> refresh the full screen at start, only parts  where it have real text 
:> to display. Ok, it's just a matter of resizing window a bit to force 
:> a display refresh, but ... as i said, it's the only bothering thing 
:> (and nearly the only reason to continue checking for new cgdb versions)
:> 
:> 
:> 
:> So, I decided to look into fixing the default color cgdb uses.
:> Well it seems that I can't find a way to do it in curses. I can only
:> find an extension to ncurses that does the trick. The 2 functions
:> use_default_colors and assume_default_colors are ncurses extensions.
:> 
:> So, I already fixed the bug by changing several lines of code in cgdb.
:> However, it only works if the user links with ncurses. Not curses.
:> So I thought maybe we should just stop supporting curses, Since it
:> doesn't by our users much.
:> 
:> What do you guys think?
:> 
:> Bobby
:
:
:
:

Re: [Cgdb-devel] ncurses vs curses

[Peter K. <pe...@ko...>]

I say we should still try to offer minimal support for curses.  Sure
throw in all the bells and whistles if you're using ncurses, but perhaps
at least try to get something usable when using curses?

- Peter

On Mon, Feb 17, 2003 at 07:02:11PM -0500, Bob Rossi wrote:
> Hi guys,
>=20
> I recieved this bug report today via Email.
>=20
> The only ( minor ) thing that bothers me is that my xterms have a white
> background by default, while cgdb use a black one, and, halas, do not=20
> refresh the full screen at start, only parts  where it have real text=20
> to display. Ok, it's just a matter of resizing window a bit to force=20
> a display refresh, but ... as i said, it's the only bothering thing=20
> (and nearly the only reason to continue checking for new cgdb versions)
>=20
>=20
>=20
> So, I decided to look into fixing the default color cgdb uses.
> Well it seems that I can't find a way to do it in curses. I can only
> find an extension to ncurses that does the trick. The 2 functions
> use_default_colors and assume_default_colors are ncurses extensions.
>=20
> So, I already fixed the bug by changing several lines of code in cgdb.
> However, it only works if the user links with ncurses. Not curses.
> So I thought maybe we should just stop supporting curses, Since it
> doesn't by our users much.
>=20
> What do you guys think?
>=20
> Bobby



--=20
Peter D. Kovacs <pe...@ko...>

[Cgdb-devel] ncurses vs curses

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

Hi guys,

I recieved this bug report today via Email.

The only ( minor ) thing that bothers me is that my xterms have a white
background by default, while cgdb use a black one, and, halas, do not=20
refresh the full screen at start, only parts  where it have real text=20
to display. Ok, it's just a matter of resizing window a bit to force=20
a display refresh, but ... as i said, it's the only bothering thing=20
(and nearly the only reason to continue checking for new cgdb versions)



So, I decided to look into fixing the default color cgdb uses.
Well it seems that I can't find a way to do it in curses. I can only
find an extension to ncurses that does the trick. The 2 functions
use_default_colors and assume_default_colors are ncurses extensions.

So, I already fixed the bug by changing several lines of code in cgdb.
However, it only works if the user links with ncurses. Not curses.
So I thought maybe we should just stop supporting curses, Since it
doesn't by our users much.

What do you guys think?

Bobby

Re: [Cgdb-devel] Configuration Stuff

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

Don't forget to add your name to the AUTHORS file. :)
Maybe update the website also.

On Wed, Feb 05, 2003 at 02:24:07PM -0500, Mike Mueller wrote:
> In my opinion, CVS should always compile.  As long as you don't=20
> break that, I don't care. :)  Besides, we most likely won't release=20
> a new CGDB until your code is done.
>=20
> Mike
>=20
> On Wed, 5 Feb 2003, Peter Kovacs wrote:
>=20
> :Okay, I've got my new "configuration" stuff handling all of the :
> :commands.  It doesn't actually parse an rc file yet (although, since
> :there are only two variables it controls, ignorecase and shortcut there
> :isn't much to put in the rc file anyway).
> :
> :Should I commit what I have now, or wait until I get the keybindings in
> :place?  Is it okay to have things in CVS that aren't necessarily ready
> :for release?
> :
> :- Peter
> :
> :
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel

Re: [Cgdb-devel] Configuration Stuff

[Mike M. <mmu...@cs...>]

In my opinion, CVS should always compile.  As long as you don't 
break that, I don't care. :)  Besides, we most likely won't release 
a new CGDB until your code is done.

Mike

On Wed, 5 Feb 2003, Peter Kovacs wrote:

:Okay, I've got my new "configuration" stuff handling all of the :
:commands.  It doesn't actually parse an rc file yet (although, since
:there are only two variables it controls, ignorecase and shortcut there
:isn't much to put in the rc file anyway).
:
:Should I commit what I have now, or wait until I get the keybindings in
:place?  Is it okay to have things in CVS that aren't necessarily ready
:for release?
:
:- Peter
:
: