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

Re: [Cgdb-devel] draw_current_line crash

[Bob R. <bo...@br...>]

On Mon, Jul 25, 2005 at 07:07:09PM -0400, Mike Mueller wrote:
> > On Sat, Jul 23, 2005 at 05:49:27AM -0400, Mike Mueller wrote:
> > OK, I'll make sure to test  this within the next few days. Also, items
> > issued to be fixed/resolved on the release schedule for .0.5.3 is below,
> >
> > - Fix runtime error with arrow style long and regex searching.
> >   I will test to make sure this is resolved within the next few days.
> >
> > - Update FAQ, it's wrong.
> >   I minor change I will fix.
> >
> > - Fix packaged readline to only build the static library, instead of
> >   both shared and static libraries.
> >   A minor, but confusing change. Don't know how to do this yet.
> >
> > - Merge in temporary breakpoint code and choose a letter for it.
> >   Can't figure out what to do on this issue. I really think 't' should
> >   set a temporary breakpoint and am considering the change. The only GDB
> >   commands that begin with 't' is,
> >
> >     tabset   tbreak   tdump    thbreak  tp       tstart   tstop    tui
> >     target   tcatch   tfind    thread   trace    tstatus  tty
> >
> >   In general, out of these options, I'm going to guess tbreak is the
> >   most used. At least it's the command I use the most. Does anyone
> >   object to this change?
>=20
> I agree that 't' is the best letter for this.  It seems like the tty
> option is not used very much since it is often easier to attach to a
> terminal-based application running in a separate window.  This kind of
> stuff definitely underscores the need for user-configurable mappings in
> the future...

OK, with that said, I'll apply the change and give tbreak the letter
't'. I'll come up with something for switching into the "tty" window.

Bob Rossi

Re: [Cgdb-devel] draw_current_line crash

[Mike M. <mi...@su...>]

> On Sat, Jul 23, 2005 at 05:49:27AM -0400, Mike Mueller wrote:
> OK, I'll make sure to test  this within the next few days. Also, items
> issued to be fixed/resolved on the release schedule for .0.5.3 is below=
,
>
> - Fix runtime error with arrow style long and regex searching.
>   I will test to make sure this is resolved within the next few days.
>
> - Update FAQ, it's wrong.
>   I minor change I will fix.
>
> - Fix packaged readline to only build the static library, instead of
>   both shared and static libraries.
>   A minor, but confusing change. Don't know how to do this yet.
>
> - Merge in temporary breakpoint code and choose a letter for it.
>   Can't figure out what to do on this issue. I really think 't' should
>   set a temporary breakpoint and am considering the change. The only GD=
B
>   commands that begin with 't' is,
>
>     tabset   tbreak   tdump    thbreak  tp       tstart   tstop    tui
>     target   tcatch   tfind    thread   trace    tstatus  tty
>
>   In general, out of these options, I'm going to guess tbreak is the
>   most used. At least it's the command I use the most. Does anyone
>   object to this change?

I agree that 't' is the best letter for this.  It seems like the tty
option is not used very much since it is often easier to attach to a
terminal-based application running in a separate window.  This kind of
stuff definitely underscores the need for user-configurable mappings in
the future...

Mike

Re: [Cgdb-devel] draw_current_line crash

[Bob R. <bo...@br...>]

On Sat, Jul 23, 2005 at 05:49:27AM -0400, Mike Mueller wrote:
> I believe the crash in draw_current_line is fixed.  I also tweaked the
> handling of tab characters, it was taking the arrow out 'n' spaces rather
> than advancing to the next tab stop.
>=20
> Please hammer on it a little bit for me, especially doing searches.  If it
> seems stable, I think it'll finally be safe to release 0.5.3. :)

OK, I'll make sure to test  this within the next few days. Also, items
issued to be fixed/resolved on the release schedule for .0.5.3 is below,

- Fix runtime error with arrow style long and regex searching.
  I will test to make sure this is resolved within the next few days.
 =20
- Update FAQ, it's wrong.
  I minor change I will fix.

- Fix packaged readline to only build the static library, instead of
  both shared and static libraries.
  A minor, but confusing change. Don't know how to do this yet.

- Merge in temporary breakpoint code and choose a letter for it.
  Can't figure out what to do on this issue. I really think 't' should
  set a temporary breakpoint and am considering the change. The only GDB
  commands that begin with 't' is,

    tabset   tbreak   tdump    thbreak  tp       tstart   tstop    tui     =
=20
    target   tcatch   tfind    thread   trace    tstatus  tty     =20

  In general, out of these options, I'm going to guess tbreak is the
  most used. At least it's the command I use the most. Does anyone
  object to this change?

Bob Rossi

[Cgdb-devel] draw_current_line crash

[Mike M. <mi...@su...>]

I believe the crash in draw_current_line is fixed.  I also tweaked the
handling of tab characters, it was taking the arrow out 'n' spaces rather
than advancing to the next tab stop.

Please hammer on it a little bit for me, especially doing searches.  If it
seems stable, I think it'll finally be safe to release 0.5.3. :)

--=20
Mike Mueller
mi...@su...

Re: [Cgdb-devel] package libreadline with CGDB

[Bob R. <bo...@br...>]

On Wed, May 25, 2005 at 07:07:35PM -0400, Bob Rossi wrote:
> Hi All,
>=20
> I've been thinking about packaging readline with CGDB.

I've finished integrating readline into CGDB in CVS. By default CGDB
will use it's internal readline. If you specify --with-readline, CGDB
will use the system readline, and if you specify --with-readline=3DPREFIX,
CGDB will use the PREFIX as the root of the readline installation.

If you use --with-readline or --with-readline=3DPREFIX and there is no
readline on the path, CGDB will still abort during configure
complaining it can not find the library. The only case it doesn't
currently handle is when there is a readline library, but it is not new
enough. I suppose this is a problem for another day.

Either way, I've successfully built CGDB on my firewall, which could
never build due to a lack of readline (and my laziness). I still have
some testing to do, but let me know how your mileage varies.

Thanks,
Bob Rossi

Re: [Cgdb-devel] patch: tbreak > press 'm' in source window

[Marcel L. <mar...@ds...>]

> OK, this is almost correct. For some reason you decided not to check the
> return code from toggle_breakpoint when you called it. If that
> function fails,
Thank you. I removed in the switch case the malloc/free for a command
string I thought was not used.

> Well, I was hoping you would release the Copyright to the patch. I don't
> think it's a terribly big deal, since this is standard practice when
> contributing code to the FSF. If the license of CGDB has to change in
> the future (If the GPL goes AWAL), I want to retain the right to do that.
A good decision. I fully support free software movement. In case of a
change, where do you track the patch,license,copyright information ? You
have to backup the mailing list.

Re: [Cgdb-devel] patch: tbreak > press 'm' in source window

[Bob R. <bo...@br...>]

Hi Marcel,

On Mon, Jul 11, 2005 at 10:18:44AM +0200, Marcel Lanz wrote:
> > Please send in the ChangeLog changes. The format for this should be
> > reasonably clear from the existing ChangeLog's.
>=20
> 07/11/2005 Marcel Lanz <mar...@ds...>
>=20
>     * README/helptext.h : added documentation for the 'm' key
>     * interface.c: dispatch breakpoint toggling with tbreak support
>     * a2-tgdb.c/tgdb_types.h : type TGDB_TBREAKPOINT_ADD for temorary bre=
akpoints

OK, this is almost correct. For some reason you decided not to check the
return code from toggle_breakpoint when you called it. If that function fai=
ls,=20
CGDB will have no way of alerting this to the user. I'll take care of this.

> > We need to have the Copyright to this patch. Is that OK with you? That
> > just ensures that we can keep CGDB under the GPL.
> Copyright is GPLv2 or later

Well, I was hoping you would release the Copyright to the patch. I don't
think it's a terribly big deal, since this is standard practice when
contributing code to the FSF. If the license of CGDB has to change in
the future (If the GPL goes AWAL), I want to retain the right to do that.

Thanks again,
Bob Rossi

Re: [Cgdb-devel] patch: tbreak > press 'm' in source window

[Marcel L. <mar...@ds...>]

> Please send in the ChangeLog changes. The format for this should be
> reasonably clear from the existing ChangeLog's.

07/11/2005 Marcel Lanz <mar...@ds...>

    * README/helptext.h : added documentation for the 'm' key
    * interface.c: dispatch breakpoint toggling with tbreak support
    * a2-tgdb.c/tgdb_types.h : type TGDB_TBREAKPOINT_ADD for temorary breakpoints

> We need to have the Copyright to this patch. Is that OK with you? That
> just ensures that we can keep CGDB under the GPL.
Copyright is GPLv2 or later

> Could you break out the regular breakpoint case statement ' ' and the
> new temporary breakpoint case statement 'm' into a function that takes a
> parameter which says if it should use a temporary or regular breakpoint.
see patch attached

regards
Marcel

Re: [Cgdb-devel] patch: tbreak > press 'm' in source window

[Mike M. <mi...@su...>]

Generally modifying user interfaces release-to-release is a bad idea,
especially in a way that's not backwards compatible with what people are
currently used to.  That said, I bet very few people are using the tty window
as it's kind of hard to understand.  I think it probably won't hurt too much
to change it...

-- 
Mike Mueller
mi...@su...

On Sun, Jul 10, 2005 at 11:48:46AM -0400, Bob Rossi wrote:
> On Sat, Jul 09, 2005 at 08:27:38AM +0200, Marcel Lanz wrote:
> > please be free to use a better key than 'm'.
> 
> Geez, what a nightmare. Does anyone have any suggestions? We currently
> use 't' to mean "Go into the inferior window". I think 't' would be more
> intuitive to people to mean "set a temporary breakpoint".
> 
> Any opinions?
> 
> Eventually, all of this stuff won't be hard coded, and people can make
> specific keys do what they want. Until then, I think it would be good to
> switch the hardcoded keys to be most user intuitive. Especially with our
> lack of documentation.
> 
> Bob Rossi

Re: [Cgdb-devel] patch: tbreak > press 'm' in source window

[Bob R. <bo...@br...>]

On Sat, Jul 09, 2005 at 08:27:38AM +0200, Marcel Lanz wrote:
> please be free to use a better key than 'm'.

Geez, what a nightmare. Does anyone have any suggestions? We currently
use 't' to mean "Go into the inferior window". I think 't' would be more
intuitive to people to mean "set a temporary breakpoint".

Any opinions?

Eventually, all of this stuff won't be hard coded, and people can make
specific keys do what they want. Until then, I think it would be good to
switch the hardcoded keys to be most user intuitive. Especially with our
lack of documentation.

Bob Rossi

Re: [Cgdb-devel] patch: tbreak > press 'm' in source window

[Marcel L. <mar...@ds...>]

On Sat, Jul 09, 2005 at 12:16:08PM -0400, Bob Rossi wrote:
> We need to have the Copyright to this patch. Is that OK with you? That
> just ensures that we can keep CGDB under the GPL.
Yes, this is ok.

> Could you break out the regular breakpoint case statement ' ' and the
> new temporary breakpoint case statement 'm' into a function that takes a
> parameter which says if it should use a temporary or regular breakpoint.
sure. I don't have my laptop here, so I'll send the patch at monday again with the changes you suggest.

marcel

Re: [Cgdb-devel] patch: tbreak > press 'm' in source window

[Bob R. <bo...@br...>]

On Sat, Jul 09, 2005 at 08:27:38AM +0200, Marcel Lanz wrote:
> please be free to use a better key than 'm'.
>=20
> regards, marcel

Thanks marcel! I can apply this to CGDB for the next release with just a
few minor changes. I plan on doing a release within the next few weeks.

Please send in the ChangeLog changes. The format for this should be
reasonably clear from the existing ChangeLog's.

Also, modify the README file to add the documentation for the new
command. You can probably cut/paste the ' ' (breakpoint) documentation.

We need to have the Copyright to this patch. Is that OK with you? That
just ensures that we can keep CGDB under the GPL.

One other minor change, see below.

> diff -Naur cgdb-0.5.2/cgdb/src/interface.c cgdb-0.5.2_tbreak/cgdb/src/int=
erface.c
> --- cgdb-0.5.2/cgdb/src/interface.c	2005-05-17 21:11:33.000000000 +0200
> +++ cgdb-0.5.2_tbreak/cgdb/src/interface.c	2005-07-09 08:20:48.676765656 =
+0200
> @@ -985,6 +985,34 @@
>                  free(command);
>              }
>              break;
> +        case 'm':
> +            {
> +                char *path;
> +                int   line;
> +                char *command;
> +				enum tgdb_breakpoint_action t;
> +
> +                if (!sview || !sview->cur || !sview->cur->path)
> +                    return;
> +
> +                line =3D sview->cur->sel_line;
> +
> +                /* Get filename (strip path off -- GDB is dumb) */
> +                path =3D strrchr(sview->cur->path, '/') + 1;
> +                if ((int) path =3D=3D 1)
> +                    path =3D sview->cur->path;
> +                   =20
> +                command =3D (char *) malloc(strlen(path) + 20);
> +			=09
> +				if ( sview->cur->buf.breakpts[line] )
> +					t =3D TGDB_BREAKPOINT_DELETE;
> +				else
> +					t =3D TGDB_TBREAKPOINT_ADD;
> +			=09
> +				tgdb_modify_breakpoint ( tgdb, path, line + 1, t );
> +                free(command);
> +            }
> +            break;
>          default:
>              break;
>      }

Could you break out the regular breakpoint case statement ' ' and the
new temporary breakpoint case statement 'm' into a function that takes a
parameter which says if it should use a temporary or regular breakpoint.

That way, you don't have to duplicate all but 1 line of the case
statment.

Thanks again,
Bob Rossi

[Cgdb-devel] patch: tbreak > press 'm' in source window

[Marcel L. <mar...@ds...>]

please be free to use a better key than 'm'.

regards, marcel

RE: [Cgdb-devel] no input when debugging OpenIPMI

[Wenqiang S. <ws...@sb...>]

This is right and BETTER. 

Thanks

-----Original Message-----
From: cgd...@li... on behalf of Bob Rossi
Sent: Fri 6/10/2005 11:28 PM
To: cgd...@li...
Subject: Re: [Cgdb-devel] no input when debugging OpenIPMI
 
Another alternative (which is the one I prefer), is to simply start 
your program in another terminal and then attach to it using CGDB.

This allows your input/output to be in one terminal, and your CGDB debug
session in another terminal.

Bob Rossi

On Fri, Jun 10, 2005 at 05:54:38PM -0600, Wenqiang Song wrote:
> Thanks. Yes I'm trying to pass input to program being debugged. And yes
what
> you said works. 
> 
> I just blindly thought it works just like gdb which uses the same window
for
> program input/output. 
> 
> Appreciate your help.
> 
> Wenqiang
> 
> -----Original Message-----
> From: cgd...@li... on behalf of Mike Mueller
> Sent: Fri 6/10/2005 7:39 PM
> To: cgd...@li...
> Subject: Re: [Cgdb-devel] no input when debugging OpenIPMI
>  
> Are you trying to pass input to the program being debugged?  If so,
> currently this must be done through cgdb's TTY window, which is opened by
> pressing 'T' in command mode.  You can then type input and view output
> from the program in this window.  ESC takes you out of the window, and 't'
> puts you back in.  These keys are documented in the (albeit highly simple)
> :help document.
> 
> Hopefully this solves your problem!
> 
> Regards,
> Mike
> 
> > Folks,
> >
> > When I debug OpenIPMI(can't be downloaded from
> > http://sourceforge.net/projects/openipmi/), after starting the program
and
> > get the command line prompt I can't input anything. The only way to exit
> > is
> > hitting Ctrl-C and return to cgdb prompt. The problem is reproducable
and
> > it
> > doesn't happen to gdb(version 6.3). Did any of you guys meet this kind
of
> > problem?
> >
> > How to reproduce:
> >
> > 1, download OpenIPMI 2.0.1 source and compile it(don't need to install)
> > 2, under dir OpenIPMI-2.0.1/ run 'cgdb cmdlang/.libs/ipmish'
> > 3, start the program, then bump.
> >
> > Best Regards
> >
> > For limitations on the use and distribution of this message, please
visit
> > www.sbs.com/emaildisclaimer.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> > shotput
> > a projector? How fast can you ride your desk chair down the office luge
> > track?
> > If you want to score the big prize, get to know the little guy.
> > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> > _______________________________________________
> > Cgdb-devel mailing list
> > Cgd...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgdb-devel
> >
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput
> a projector? How fast can you ride your desk chair down the office luge
> track?
> If you want to score the big prize, get to know the little guy.  
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel
> 
> ***This message has been scanned for virus, spam, and undesirable
> content.***
> ***For further information, contact your mail administrator.***
> 
> 
> 
> For limitations on the use and distribution of this message, please visit
www.sbs.com/emaildisclaimer.




For limitations on the use and distribution of this message, please visit www.sbs.com/emaildisclaimer.

Re: [Cgdb-devel] Problem when setting breakpoint in function which is out of curre nt scope

[Bob R. <bo...@br...>]

On Fri, Jun 10, 2005 at 06:11:35PM -0600, Wenqiang Song wrote:
> If using gdb, when you set up a breakpoint in a function that's out of
> current scope it will ask:
>=20
> Function "xxx" not defined.
> Make breakpoint pending on future shared library load? (y or [n])
>=20
> But in cgdb it just simply says "Function "xxx" not defined." So how can I
> setup such a breakpoint in cgdb?

I've been told of this problem before but have not had time to look into
it. I have a feeling that this is a GDB issue. I'll let you know soon if
there is some sort of configuration option that will allow this to work.

Thanks,
Bob Rossi

Re: [Cgdb-devel] no input when debugging OpenIPMI

[Bob R. <bo...@br...>]

Another alternative (which is the one I prefer), is to simply start=20
your program in another terminal and then attach to it using CGDB.

This allows your input/output to be in one terminal, and your CGDB debug
session in another terminal.

Bob Rossi

On Fri, Jun 10, 2005 at 05:54:38PM -0600, Wenqiang Song wrote:
> Thanks. Yes I'm trying to pass input to program being debugged. And yes w=
hat
> you said works.=20
>=20
> I just blindly thought it works just like gdb which uses the same window =
for
> program input/output.=20
>=20
> Appreciate your help.
>=20
> Wenqiang
>=20
> -----Original Message-----
> From: cgd...@li... on behalf of Mike Mueller
> Sent: Fri 6/10/2005 7:39 PM
> To: cgd...@li...
> Subject: Re: [Cgdb-devel] no input when debugging OpenIPMI
> =20
> Are you trying to pass input to the program being debugged?  If so,
> currently this must be done through cgdb's TTY window, which is opened by
> pressing 'T' in command mode.  You can then type input and view output
> from the program in this window.  ESC takes you out of the window, and 't'
> puts you back in.  These keys are documented in the (albeit highly simple)
> :help document.
>=20
> Hopefully this solves your problem!
>=20
> Regards,
> Mike
>=20
> > Folks,
> >
> > When I debug OpenIPMI(can't be downloaded from
> > http://sourceforge.net/projects/openipmi/), after starting the program =
and
> > get the command line prompt I can't input anything. The only way to exit
> > is
> > hitting Ctrl-C and return to cgdb prompt. The problem is reproducable a=
nd
> > it
> > doesn't happen to gdb(version 6.3). Did any of you guys meet this kind =
of
> > problem?
> >
> > How to reproduce:
> >
> > 1, download OpenIPMI 2.0.1 source and compile it(don't need to install)
> > 2, under dir OpenIPMI-2.0.1/ run 'cgdb cmdlang/.libs/ipmish'
> > 3, start the program, then bump.
> >
> > Best Regards
> >
> > For limitations on the use and distribution of this message, please vis=
it
> > www.sbs.com/emaildisclaimer.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> > shotput
> > a projector? How fast can you ride your desk chair down the office luge
> > track?
> > If you want to score the big prize, get to know the little guy.
> > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> > _______________________________________________
> > Cgdb-devel mailing list
> > Cgd...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgdb-devel
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput
> a projector? How fast can you ride your desk chair down the office luge
> track?
> If you want to score the big prize, get to know the little guy. =20
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel
>=20
> ***This message has been scanned for virus, spam, and undesirable
> content.***
> ***For further information, contact your mail administrator.***
>=20
>=20
>=20
> For limitations on the use and distribution of this message, please visit=
 www.sbs.com/emaildisclaimer.

[Cgdb-devel] Problem when setting breakpoint in function which is out of curre nt scope

[Wenqiang S. <ws...@sb...>]

If using gdb, when you set up a breakpoint in a function that's out of
current scope it will ask:

Function "xxx" not defined.
Make breakpoint pending on future shared library load? (y or [n])

But in cgdb it just simply says "Function "xxx" not defined." So how can I
setup such a breakpoint in cgdb?

Best
Wenqiang


For limitations on the use and distribution of this message, please visit www.sbs.com/emaildisclaimer.

RE: [Cgdb-devel] no input when debugging OpenIPMI

[Wenqiang S. <ws...@sb...>]

Thanks. Yes I'm trying to pass input to program being debugged. And yes what
you said works. 

I just blindly thought it works just like gdb which uses the same window for
program input/output. 

Appreciate your help.

Wenqiang

-----Original Message-----
From: cgd...@li... on behalf of Mike Mueller
Sent: Fri 6/10/2005 7:39 PM
To: cgd...@li...
Subject: Re: [Cgdb-devel] no input when debugging OpenIPMI
 
Are you trying to pass input to the program being debugged?  If so,
currently this must be done through cgdb's TTY window, which is opened by
pressing 'T' in command mode.  You can then type input and view output
from the program in this window.  ESC takes you out of the window, and 't'
puts you back in.  These keys are documented in the (albeit highly simple)
:help document.

Hopefully this solves your problem!

Regards,
Mike

> Folks,
>
> When I debug OpenIPMI(can't be downloaded from
> http://sourceforge.net/projects/openipmi/), after starting the program and
> get the command line prompt I can't input anything. The only way to exit
> is
> hitting Ctrl-C and return to cgdb prompt. The problem is reproducable and
> it
> doesn't happen to gdb(version 6.3). Did any of you guys meet this kind of
> problem?
>
> How to reproduce:
>
> 1, download OpenIPMI 2.0.1 source and compile it(don't need to install)
> 2, under dir OpenIPMI-2.0.1/ run 'cgdb cmdlang/.libs/ipmish'
> 3, start the program, then bump.
>
> Best Regards
>
> For limitations on the use and distribution of this message, please visit
> www.sbs.com/emaildisclaimer.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput
> a projector? How fast can you ride your desk chair down the office luge
> track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel
>




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
shotput
a projector? How fast can you ride your desk chair down the office luge
track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Cgdb-devel mailing list
Cgd...@li...
https://lists.sourceforge.net/lists/listinfo/cgdb-devel

***This message has been scanned for virus, spam, and undesirable
content.***
***For further information, contact your mail administrator.***



For limitations on the use and distribution of this message, please visit www.sbs.com/emaildisclaimer.

Re: [Cgdb-devel] no input when debugging OpenIPMI

[Mike M. <mi...@su...>]

Are you trying to pass input to the program being debugged?  If so,
currently this must be done through cgdb's TTY window, which is opened by
pressing 'T' in command mode.  You can then type input and view output
from the program in this window.  ESC takes you out of the window, and 't=
'
puts you back in.  These keys are documented in the (albeit highly simple=
)
:help document.

Hopefully this solves your problem!

Regards,
Mike

> Folks,
>
> When I debug OpenIPMI(can't be downloaded from
> http://sourceforge.net/projects/openipmi/), after starting the program =
and
> get the command line prompt I can't input anything. The only way to exi=
t
> is
> hitting Ctrl-C and return to cgdb prompt. The problem is reproducable a=
nd
> it
> doesn't happen to gdb(version 6.3). Did any of you guys meet this kind =
of
> problem?
>
> How to reproduce:
>
> 1, download OpenIPMI 2.0.1 source and compile it(don't need to install)
> 2, under dir OpenIPMI-2.0.1/ run 'cgdb cmdlang/.libs/ipmish'
> 3, start the program, then bump.
>
> Best Regards
>
> For limitations on the use and distribution of this message, please vis=
it
> www.sbs.com/emaildisclaimer.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput
> a projector? How fast can you ride your desk chair down the office luge
> track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel
>

[Cgdb-devel] no input when debugging OpenIPMI

[Wenqiang S. <ws...@sb...>]

Folks,

When I debug OpenIPMI(can't be downloaded from
http://sourceforge.net/projects/openipmi/), after starting the program and
get the command line prompt I can't input anything. The only way to exit is
hitting Ctrl-C and return to cgdb prompt. The problem is reproducable and it
doesn't happen to gdb(version 6.3). Did any of you guys meet this kind of
problem?

How to reproduce:

1, download OpenIPMI 2.0.1 source and compile it(don't need to install)
2, under dir OpenIPMI-2.0.1/ run 'cgdb cmdlang/.libs/ipmish'
3, start the program, then bump.

Best Regards

For limitations on the use and distribution of this message, please visit www.sbs.com/emaildisclaimer.

Re: [Cgdb-devel] package libreadline with CGDB

[Robert L. <rob...@se...>]

On Wed, May 25, 2005 at 07:07:35PM -0400, Bob Rossi wrote:
> I've been thinking about packaging readline with CGDB. CGDB needs a
> fairly new version of readline to work. I find that people also download

well, the original idea of a shared library is that people don't have to
ship the same code with multiple programs, so it is a bad idea.
that said, readline is a bit problematic and i fully understand that you
have problems with it, so if it helps to link it statically against a
new version, go for it.

but please include a configure option to turn usage of the included
libreadline off, systems like debian (and probably many others) wouldn't
want to ship a statically linked binary.

cu  robert

--=20
Robert Lemmen                               http://www.semistable.com=20

Re: [Cgdb-devel] package libreadline with CGDB

[Bob R. <bo...@br...>]

On Thu, May 26, 2005 at 10:34:56AM -0400, Mike Mueller wrote:
> I don't see a problem with including readline.  We would statically link
> to it, rather than install a new readline.so on the user's machine, right?
>=20
> Mike

Yeah, that was what I was thinking, but I wanted to see what others
thought would be a good idea. There is a few options.

   - Always link static against the packaged version.
   - Same as above, but provide a configure option not to use the
     packaged version.
   - Only link against the packaged version if the system doesn't have a
     version that works with CGDB

Either way, by default, we would link statically against readline. We
could provide a configure option to install readline, and then link
against the installed version, but all of this just get's more and more
complicated.

I think I like the idea of distribuing readline and linking statically
against it. Maybe provide an option to not use the packaged version.
Either way, when a new version of readline comes out, I'll simply
release a new version of CGDB with that version of readline. This would
probably provide the best of both worlds.

Thanks,
Bob Rossi

> > Hi All,
> >
> > I've been thinking about packaging readline with CGDB. CGDB needs a
> > fairly new version of readline to work. I find that people also download
> > CGDB, configure it, find out it doesn't configure because of readline,
> > and then that starts them on a never ending cycle of not being able to
> > configure CGDB.
> >
> > Either way, I've had several patches received into the development
> > version of readline. Once the next version of readline is released, CGDB
> > will depend on it. This change is needed to greatly improve the internal
> > structure of CGDB. In particular, CGDB will no longer have to fork in
> > order to communicate with readline. This is a great, and much needed
> > change.
> >
> > I was thinking about importing readline into CGDB for the next minor
> > release of CGDB (which could be soon). Does anyone think this is a bad
> > idea? or problematic? Any advice?
> >
> > Thanks,
> > Bob Rossi
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22=
005
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel

Re: [Cgdb-devel] package libreadline with CGDB

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

I don't see a problem with including readline.  We would statically link
to it, rather than install a new readline.so on the user's machine, right=
?

Mike


> Hi All,
>
> I've been thinking about packaging readline with CGDB. CGDB needs a
> fairly new version of readline to work. I find that people also downloa=
d
> CGDB, configure it, find out it doesn't configure because of readline,
> and then that starts them on a never ending cycle of not being able to
> configure CGDB.
>
> Either way, I've had several patches received into the development
> version of readline. Once the next version of readline is released, CGD=
B
> will depend on it. This change is needed to greatly improve the interna=
l
> structure of CGDB. In particular, CGDB will no longer have to fork in
> order to communicate with readline. This is a great, and much needed
> change.
>
> I was thinking about importing readline into CGDB for the next minor
> release of CGDB (which could be soon). Does anyone think this is a bad
> idea? or problematic? Any advice?
>
> Thanks,
> Bob Rossi
>

[Cgdb-devel] package libreadline with CGDB

[Bob R. <bo...@br...>]

Hi All,

I've been thinking about packaging readline with CGDB. CGDB needs a
fairly new version of readline to work. I find that people also download
CGDB, configure it, find out it doesn't configure because of readline,
and then that starts them on a never ending cycle of not being able to
configure CGDB.

Either way, I've had several patches received into the development
version of readline. Once the next version of readline is released, CGDB
will depend on it. This change is needed to greatly improve the internal
structure of CGDB. In particular, CGDB will no longer have to fork in
order to communicate with readline. This is a great, and much needed
change.

I was thinking about importing readline into CGDB for the next minor
release of CGDB (which could be soon). Does anyone think this is a bad
idea? or problematic? Any advice?

Thanks,
Bob Rossi

Re: [Cgdb-devel] Re: cgdb 0.5.1 make DESTDIR=... doesn't work

[Bob R. <bo...@br...>]

On Sat, May 21, 2005 at 07:15:03PM +0200, Robert Lemmen wrote:
> On Sat, May 21, 2005 at 12:35:11PM -0400, Bob Rossi wrote:
> > Is there any chance that you could both try to build CGDB for your
> > distro's? I believe I have fixed the problems that you have reported.
> > Robert, hopefully you should be able to build CGDB without any patches
> > to the autoconf stuff. Benett, hopefully you should be able to do 'make
> > DESTDIR=3D... install'.
> >=20
> > Please let me know as soon as possible. I've found a critical bug in
> > CGDB on platforms other than linux and want to put up another minor
> > release.
>=20
> i checked out the current cvs version, and tried a debian build on it.
> works like a charm! that's really cool to see. if you are doing a new
> version i have two more things to throw in:

Great, I'm glad to hear it.

> - could you update the config.sub and config.guess files to current
>   versions? it would make it easier to build under weird systems
>   (like GNU/kFreeBSD). you just need to copy over newer files,
>   everything from 2005 should be fine

Weird, I thought I already did that. It's done now.

> - i wrote a manual page for debian, but it's really bad and should be in
>   the upstream source anyway. perhaps you want to have a quick look, fix
>   the most stupid mistakes and put it into your cvs

Let's do this for the next release, since I have little time and need to
get this fix out as soon as possible. I know we talked about this
before, however, is there any way to generate a man page and a .txt from
a single document? This way, there is no duplication of information. If
there is a relatively easy way, I'd like to do that.

Thanks for the very quick response. If you don't mind, please try doing
a debian build again from CVS. This has the latest autoconf/automake
changes. If you have good results, I'll probably do a release later
today.

Thanks,
Bob Rossi