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

Re: [Cgdb-devel] TGDB architecture

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

On Wed, Sep 17, 2003 at 03:52:16PM -0400, Alain Magloire wrote:
> The GUI user is making an action(This is a single threaded UI application=
) so
> GDB does not respond(i.e. the select() says nothing is available).
> Since this is a GUI .... there is no CTRL-C tty for the user to hit.
> Since this is a single threaded application ... well the button(Cancel) is
> not refreshing  because the UI thread is block on select() so can not
> process any mouse event ...
>=20
> Basically in the eye of the GUI user the application is hanging.
> =20

Sorry, I read this too quickly before.  The idea of sending a SIGINT
still works.=20

However, the point is tgdb will never block on select or read: there are
no select calls in tgdb.  The GUI should always have control, and will
only execute tgdb code when there is input.

- Peter

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

Re: [Cgdb-devel] TGDB architecture

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

On Wed, Sep 17, 2003 at 03:52:16PM -0400, Alain Magloire wrote:
> The GUI user is making an action(This is a single threaded UI application=
) so
> GDB does not respond(i.e. the select() says nothing is available).
> Since this is a GUI .... there is no CTRL-C tty for the user to hit.
> Since this is a single threaded application ... well the button(Cancel) is
> not refreshing  because the UI thread is block on select() so can not
> process any mouse event ...

There could be an 'Interrupt' button that sends a SIGINT, which would
accomplish the same thing.

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

Re: [Cgdb-devel] TGDB architecture

[Alain M. <al...@qn...>]

> 
> 
> --OwLcNYc0lM97+oe1
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> > TGDB, if I understand correctly, is a general debug interface library
> > that can be use by _any_ application, it happens that the only user of th=
> e library
> > is currently "cgdb".  So keeping in mind that TGDB is general library, you
> > do not know how different application will make  use of it.
> >=20
> > > > What is the recovery when gdb goes to debugger heaven ?
> > >=20
> > > TGDB has no problem when GDB crashes. I think that what you mean here,
> > > right?
> > >=20
> >=20
> > ye/no, gdb does not crash, it still running but not responding to
> > any activiy, its just block.
> >=20
> > How as an application waiting for feedback can I break out of this ?
> 

I do not know, how you manage to decypher my emails with all the typos 8-)

> Currently, TGDB does not have a select loop. TGDB in general, is only
> called when the front end determines ( via select or something else )=20
> output has been given by GDB, the inferior or readline. TGDB than
> reads as much as it can from the descriptor, process's it, then returns
> control to the front end ( with commands or not ).
> 
> The application does not hang when GDB is busy, because TGDB returns
> control to the front end until more output from GDB is available.
> However, if the user does not want GDB to finish its long command, it
> could always send a ^c to stop the current command. In this respect,
> TGDB seems to manage well.
> 

Ho! I see, Ok.

But you are still looking at this in command line bias manner, let me give you
a scenario, a GUI application:

GUI user are not very smart 8-), in the sense that they expect the application
to handle things for them.

  | GUI | --> | Library_Adapter | --> | TGDB |


The GUI user is making an action(This is a single threaded UI application) so
GDB does not respond(i.e. the select() says nothing is available).
Since this is a GUI .... there is no CTRL-C tty for the user to hit.
Since this is a single threaded application ... well the button(Cancel) is
not refreshing  because the UI thread is block on select() so can not
process any mouse event ...

Basically in the eye of the GUI user the application is hanging.
 
> > > Currently, it return TGDB_QUIT to the front end, and then CGDB just
> > > shuts down. It appears that CGDB doesn't work properly but thats just
> > > what we decided to do for now. The reason is because TGDB just reads a
> > > 'EOF' when TGDB dies, and currently it doesn't know if the EOF is
> > > because of normal or abnormal termination.
> > >=20
> > > Do you have any suggestions on making this better?
> >=20
> > Selection timeout, if the read() does not return after xx time?
> > Again it may not be a priority at this point, adding this kind of thing
> > can make the code very complex ...  and something you do not need at this
> > early stage.
> 
> The read should never hang because the select loop was triggered by the
> front. TGDB should never to a blocking read. The only thing that hasn't
> been considered to well is what happens if TGDB does a blocking write
> call.
> 

See above.
It does not matter what function is blocking, the select() or the read(),
especially when you are single threaded.
At least with the select() you can have a timeout say 2 minutes(configurable).
This will allow the application to continue and the UI to popup a dialog
message :
"GDB is not responding" or something .

Re: [Cgdb-devel] TGDB structures

[Alain M. <al...@qn...>]

..

> > it is not very complicated either: a non-blocking way of verifying whether
> > your pointer is still OK before writing to it is available on all ix86=20
> > platforms since the 486; it's available on the Sparc (though I don't know
> > since when) and on many other chips. And if a non-blocking way to do it
> > is not available, a fine-grained blocking implementation can be (almost) =
> just
> > as fast.
> 
> I think leaving out the possibility of threading could be a mistake.
> We should probably at least design TGDB in a way where it is thread
> safe capable. Even if it doesn't support multi-threaded applications.
> I don't know much about threaded applications, but it seems like Ronald
> is stating the an ADT would support threads a little better that a
> simple linked list. ( depending on the implementation of the ADT )
> 
> Any other considerations?
> 
> I really hope to only do this once. As I am tired of going back to
> change things that were not well thought out in the first place. The
> structures are particularly important because they are really the only
> thing that will affect all front ends.
> 

8-)
You have to realize you will never get things right the first time,
simply not possible.
My point was to bring this to your attention as you were asking
for feeback.

The MI front end that we did is "Thread-safe" but not "Reentrant".
There is a distinction.  It's thread-safe that you can use
multiple thread and the library will serialize the requests if
need be ore does not carry any state that can make the use of
thread impossible.  It is not "reentrant" meaning that it serialize
commands and trying to recall/reenter a command may mean deadlock.

That sayd, If you say that in version 1.0 of tgdb you folks
will not worry about threads and will tackle the issue only in
2.0 ... that's certainly reasonnable.  Some issues can be
deal better with some later version, when the direction is better understood.

my 0.0002 canadian.

Re: [Cgdb-devel] TGDB detects when GDB goes psycho!

[Alain M. <al...@qn...>]

> 
> 
> --Qxx1br4bt0+wmkIi
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> Hi,
> 
> =46rom now on, TGDB will return TGDB_QUIT_NORMAL when it thinks that GDB
> has quit normally. It will return TGDB_QUIT_ABNORMAL when it thinks that
> GDB crashed or dies unexpectedly.
> 

In the case of NORMAL you need to pass back the exit code of the inferior
in ABNORMAL you do not so .. yes the distinction is important.

> I don't know if someone wants to work on CGDB to handle these cases
> appropriately. Currently, CGDB quits either way. It would be cool if it
> printed a message to the user, telling them that GDB died. This way we
> can tell the difference between when CGDB crashes and GDB crashes.
> 
> Bob Rossi

Re: [Cgdb-devel] TGDB architecture

[Alain M. <al...@qn...>]

> 
> 
> --76DTJ5CE0DCVQemd
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Fri, Sep 12, 2003 at 07:41:19PM -0400, Bob Rossi wrote:
> > I have made a significant effort to make TGDB context driven over the
> > last several months. That seems to be done now. However, since TGDB was
> > not designed with either of these goals in mind, there are places in the
> > code were there are static variables defined in functions. Thus, it is
> > probably not thread safe. These things are probably easy to solve.
> 
> I'm pretty sure this is all that's necessary.  Eliminate all static
> variables in functions so that they are fully reentrant (can be called
> interrupted and called again with no problems).  The stuff you've done
> to convert things to the context driven interface is a huge step in the
> right direction. =20
> 

Agreed.

> Keep in mind that, in general, GUI programs are single threaded.  Right

Yes/No, many GUI programs will use one thread to do graphics(for example
Java/Swing, eclipse/SWT etc ...) but that does not mean they are single threaded.
SWT gui applications and Swing also use a lot of threads to handle many
tasks that are not necessarly GUI related.  Accessing some information in
GDB does not strike me of GUI related.

Again not a priority.
 
> now, the only major hang up with a GUI program using tgdb is accessing
> tgdbs file descriptors.  We may need some more work in this area (and
> really, could probably only find all the bugs if somebody actually
> writes a GUI based on tgdb).
> 
> >=20
> > > What is the recovery when gdb goes to debugger heaven ?
> >=20
> > TGDB has no problem when GDB crashes. I think that what you mean here,
> > right?
> >=20
> > Currently, it return TGDB_QUIT to the front end, and then CGDB just
> > shuts down. It appears that CGDB doesn't work properly but thats just
> > what we decided to do for now. The reason is because TGDB just reads a
> > 'EOF' when TGDB dies, and currently it doesn't know if the EOF is
> > because of normal or abnormal termination.
> 
> Couldn't we check the return val of a waitpid call when we receive the
> EOF?  That's the usual manner to check to see if a program exited
> abnormally.
> 

The problem is when gdb is not respondig.  When gdb crashes that's
fine the pipe() will be close by the kerner and read() will fail.

Re: [Cgdb-devel] TGDB architecture

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

> TGDB, if I understand correctly, is a general debug interface library
> that can be use by _any_ application, it happens that the only user of th=
e library
> is currently "cgdb".  So keeping in mind that TGDB is general library, you
> do not know how different application will make  use of it.
>=20
> > > What is the recovery when gdb goes to debugger heaven ?
> >=20
> > TGDB has no problem when GDB crashes. I think that what you mean here,
> > right?
> >=20
>=20
> ye/no, gdb does not crash, it still running but not responding to
> any activiy, its just block.
>=20
> How as an application waiting for feedback can I break out of this ?

Currently, TGDB does not have a select loop. TGDB in general, is only
called when the front end determines ( via select or something else )=20
output has been given by GDB, the inferior or readline. TGDB than
reads as much as it can from the descriptor, process's it, then returns
control to the front end ( with commands or not ).

The application does not hang when GDB is busy, because TGDB returns
control to the front end until more output from GDB is available.
However, if the user does not want GDB to finish its long command, it
could always send a ^c to stop the current command. In this respect,
TGDB seems to manage well.

> > Currently, it return TGDB_QUIT to the front end, and then CGDB just
> > shuts down. It appears that CGDB doesn't work properly but thats just
> > what we decided to do for now. The reason is because TGDB just reads a
> > 'EOF' when TGDB dies, and currently it doesn't know if the EOF is
> > because of normal or abnormal termination.
> >=20
> > Do you have any suggestions on making this better?
>=20
> Selection timeout, if the read() does not return after xx time?
> Again it may not be a priority at this point, adding this kind of thing
> can make the code very complex ...  and something you do not need at this
> early stage.

The read should never hang because the select loop was triggered by the
front. TGDB should never to a blocking read. The only thing that hasn't
been considered to well is what happens if TGDB does a blocking write
call.

Bob Rossi

Re: [Cgdb-devel] TGDB architecture

[Alain M. <al...@qn...>]

> 
> On Fri, Sep 12, 2003 at 11:35:21AM -0400, Alain Magloire wrote:
> > Bonjour
> >=20
> > 	hum ... this is more of a test, to check subscribtion 8-)
> 
> Yay, it works!
> 

8-)

> > Is part of TGDB desing, support for threaded clients ?
> 
> Ok, TGDB was initially not designed to handle threaded clients. It was
> also initially not designed to be context driven.=20
> 
> I have made a significant effort to make TGDB context driven over the
> last several months. That seems to be done now. However, since TGDB was
> not designed with either of these goals in mind, there are places in the
> code were there are static variables defined in functions. Thus, it is
> probably not thread safe. These things are probably easy to solve.
> 
> There are several issues in mind. TGDB will probably never be thread
> safe to the point where a front end calls the same function on the same
> context together. There are no mutex's in TGDB to stop such things.
> However, if the front end calls the same function with 2 different
> contexts at the same time, that should be fine.
> 
> Personally I have never written a threaded program, I have only read and
> studied about them ... do you think what I am saying here is going in=20
> the right direction?
> 

Yes.  It is just something to keep in mind.  I think for now
you have other priorities 8-).

> I am not sure exactly what it would mean to make TGDB fully thread safe
> for clients.
> 

TGDB, if I understand correctly, is a general debug interface library
that can be use by _any_ application, it happens that the only user of the library
is currently "cgdb".  So keeping in mind that TGDB is general library, you
do not know how different application will make  use of it.

> > What is the recovery when gdb goes to debugger heaven ?
> 
> TGDB has no problem when GDB crashes. I think that what you mean here,
> right?
> 

ye/no, gdb does not crash, it still running but not responding to
any activiy, its just block.

How as an application waiting for feedback can I break out of this ?

> Currently, it return TGDB_QUIT to the front end, and then CGDB just
> shuts down. It appears that CGDB doesn't work properly but thats just
> what we decided to do for now. The reason is because TGDB just reads a
> 'EOF' when TGDB dies, and currently it doesn't know if the EOF is
> because of normal or abnormal termination.
> 
> Do you have any suggestions on making this better?

Selection timeout, if the read() does not return after xx time?
Again it may not be a priority at this point, adding this kind of thing
can make the code very complex ...  and something you do not need at this
early stage.

Re: [Cgdb-devel] TGDB structures

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

On Wed, Sep 17, 2003 at 05:06:38PM +0200, Ronald Landheer-Cieslak wrote:
> On Wed, Sep 17, 2003 at 10:15:34AM -0400, Peter Kovacs wrote:
> > On Wed, Sep 17, 2003 at 09:53:06AM -0400, Mike Mueller wrote:
> > > On Wed, 17 Sep 2003, Peter Kovacs wrote:
> > >=20
> > > :While having a generic list package is helpful, its pretty easy to m=
ake
> > > :a linked list, just by sticking a 'next' pointer at the end of a str=
uct.
> > > :I'm just sayin, is all.
> > >=20
> > > The point of this exercise was that a 'next' pointer in a struct is=
=20
> > > not a very abstract way to make a list.  I'm not a fan of having to=
=20
> > > mess with pointers every time you want to manipulate a list.  I=20
> > > think if we do make a list type, it should have a set of functions=20
> > > that operates on it and makes it reliable.
> >=20
> > Well, it would be easy enough to create a set of macro's to do anything
> > you wanted.  Heck if you put the next pointer first in the struct, they
> > could be functions (we all know how much bob hates macros).
> >=20
> > I just think its a bit of a waste to go around making generic list
> > packages when there are already so many of them out there (although
> > Ronald brings up a good point about dependencies), and its not strictly
> > necessary.  Sure it might only take a few hours to write, I just don't
> > see the point.
> >=20
> > One benefit of having the next pointer is that when you're manipulating
> > an element of the list, you don't have to back out to get to the next
> > element: everything is internalized.
> I don't know whether it's a real concern for cgdb, but there is thread-sa=
fety
> to concern, which makes a good implementation of a list a bit less trivial
> than simply maintaining a next pointer - as the actual next pointer may
> well change right under your nose..
>=20
> If thread-safety is not a concern, then I don't see much of a point in=20
> making a generic API for lists either (though it does tend to become a=20
> concern later on..)
>=20
> Still, though it may not be as trivial as having a next pointer in a stru=
ct,
> it is not very complicated either: a non-blocking way of verifying whether
> your pointer is still OK before writing to it is available on all ix86=20
> platforms since the 486; it's available on the Sparc (though I don't know
> since when) and on many other chips. And if a non-blocking way to do it
> is not available, a fine-grained blocking implementation can be (almost) =
just
> as fast.

I think leaving out the possibility of threading could be a mistake.
We should probably at least design TGDB in a way where it is thread
safe capable. Even if it doesn't support multi-threaded applications.
I don't know much about threaded applications, but it seems like Ronald
is stating the an ADT would support threads a little better that a
simple linked list. ( depending on the implementation of the ADT )

Any other considerations?

I really hope to only do this once. As I am tired of going back to
change things that were not well thought out in the first place. The
structures are particularly important because they are really the only
thing that will affect all front ends.

Bob Rossi

Re: [Cgdb-devel] TGDB structures

[Ronald Landheer-C. <bly...@us...>]

On Wed, Sep 17, 2003 at 10:15:34AM -0400, Peter Kovacs wrote:
> On Wed, Sep 17, 2003 at 09:53:06AM -0400, Mike Mueller wrote:
> > On Wed, 17 Sep 2003, Peter Kovacs wrote:
> > 
> > :While having a generic list package is helpful, its pretty easy to make
> > :a linked list, just by sticking a 'next' pointer at the end of a struct.
> > :I'm just sayin, is all.
> > 
> > The point of this exercise was that a 'next' pointer in a struct is 
> > not a very abstract way to make a list.  I'm not a fan of having to 
> > mess with pointers every time you want to manipulate a list.  I 
> > think if we do make a list type, it should have a set of functions 
> > that operates on it and makes it reliable.
> 
> Well, it would be easy enough to create a set of macro's to do anything
> you wanted.  Heck if you put the next pointer first in the struct, they
> could be functions (we all know how much bob hates macros).
> 
> I just think its a bit of a waste to go around making generic list
> packages when there are already so many of them out there (although
> Ronald brings up a good point about dependencies), and its not strictly
> necessary.  Sure it might only take a few hours to write, I just don't
> see the point.
> 
> One benefit of having the next pointer is that when you're manipulating
> an element of the list, you don't have to back out to get to the next
> element: everything is internalized.
I don't know whether it's a real concern for cgdb, but there is thread-safety
to concern, which makes a good implementation of a list a bit less trivial
than simply maintaining a next pointer - as the actual next pointer may
well change right under your nose..

If thread-safety is not a concern, then I don't see much of a point in 
making a generic API for lists either (though it does tend to become a 
concern later on..)

Still, though it may not be as trivial as having a next pointer in a struct,
it is not very complicated either: a non-blocking way of verifying whether
your pointer is still OK before writing to it is available on all ix86 
platforms since the 486; it's available on the Sparc (though I don't know
since when) and on many other chips. And if a non-blocking way to do it
is not available, a fine-grained blocking implementation can be (almost) just
as fast.

rlc

-- 
A long memory is the most subversive idea in America.

Re: [Cgdb-devel] TGDB structures

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

On Wed, Sep 17, 2003 at 09:53:06AM -0400, Mike Mueller wrote:
> On Wed, 17 Sep 2003, Peter Kovacs wrote:
>=20
> :While having a generic list package is helpful, its pretty easy to make
> :a linked list, just by sticking a 'next' pointer at the end of a struct.
> :I'm just sayin, is all.
>=20
> The point of this exercise was that a 'next' pointer in a struct is=20
> not a very abstract way to make a list.  I'm not a fan of having to=20
> mess with pointers every time you want to manipulate a list.  I=20
> think if we do make a list type, it should have a set of functions=20
> that operates on it and makes it reliable.

Well, it would be easy enough to create a set of macro's to do anything
you wanted.  Heck if you put the next pointer first in the struct, they
could be functions (we all know how much bob hates macros).

I just think its a bit of a waste to go around making generic list
packages when there are already so many of them out there (although
Ronald brings up a good point about dependencies), and its not strictly
necessary.  Sure it might only take a few hours to write, I just don't
see the point.

One benefit of having the next pointer is that when you're manipulating
an element of the list, you don't have to back out to get to the next
element: everything is internalized.

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

Re: [Cgdb-devel] TGDB structures

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

On Wed, 17 Sep 2003, Peter Kovacs wrote:

:While having a generic list package is helpful, its pretty easy to make
:a linked list, just by sticking a 'next' pointer at the end of a struct.
:I'm just sayin, is all.

The point of this exercise was that a 'next' pointer in a struct is 
not a very abstract way to make a list.  I'm not a fan of having to 
mess with pointers every time you want to manipulate a list.  I 
think if we do make a list type, it should have a set of functions 
that operates on it and makes it reliable.

:You can still do the tgdb_get_command, if you pass an opaque iterator
:around.  Check out the Iterator design pattern (in the book, "Design
:Patterns").  Personally, I think the less mucking around inside the tgdb
:api, the better.  

The iterator isn't needed, the TGDB context will handle it.

:- Peter

Mike

:On Wed, Sep 17, 2003 at 08:27:16AM -0400, Bob Rossi wrote:
:> Ok, well then that settles it. We will not use glib for TGDB. I will
:> write up a quick implementation of 'struct tgdb_list'. Then I will
:> export that to the front end side. So, all front end writers will have
:> to manipulate tgdb_list structures.
:> 
:> If anyone can think of anything better, let me know.
:> 
:> Hey Peter, do you still like the idea of 'tgdb_get_command()' even
:> though we have the list implementation now? I could just return a
:> tgdb_list of commands. For some strange reason, I still kind of like the
:> tgdb_get_command() function. It avoids the list of list problem. If
:> that can be called a problem.
:> 
:> A list of commands. Where each command can have a list of breakpoints,
:> or a list of frames ...
:> 
:> Sometimes I am not sure if these little details even matter :)
:> 
:> Bob Rossi
:> 
:> On Wed, Sep 17, 2003 at 12:31:16PM +0200, Ronald Landheer-Cieslak wrote:
:> > On Tue, Sep 16, 2003 at 06:30:32PM -0400, Bob Rossi wrote:
:> > > I was seriously thinking about making TGDB depend on Glib.
:> > > What do you guys think?
:> > > 
:> > > This is really important since we would be exporting lists of type Glist
:> > > to the front ends? Are there any objections? Or better solutions?
:> > IMHO, that would not be a good idea. You'd loose portability for some of 
:> > the platforms cgdb currently works under (including Cygwin, as glib is not
:> > part of the Cygwin distribution).
:> > 
:> > You could, of course, make the dependency optional, but the problem with 
:> > optional dependencies is that they tend to become maintenance nightmares
:> > rather quickly.
:> > 
:> > Personally, I'd probably opt for making a light-weight list implementation
:> > if you really need one for tgdb. Lists are not that hard to implement 
:> > efficiently.
:> > 
:> > Just my opinion, of course, but I would like to avoid cgdb depending on 
:> > anything not in the Cygwin distribution, as it would make it a bit harder 
:> > to maintain a cgdb version for Cygwin :|
:> > 
:> > rlc
:> > 
:> > -- 
:> > Television has proved that people will look at anything rather than each other.
:> > 		-- Ann Landers
:> > 
:> > 
:> > -------------------------------------------------------
:> > This sf.net email is sponsored by:ThinkGeek
:> > Welcome to geek heaven.
:> > http://thinkgeek.com/sf
:> > _______________________________________________
:> > Cgdb-devel mailing list
:> > Cgd...@li...
:> > https://lists.sourceforge.net/lists/listinfo/cgdb-devel
:
:
:
:

Re: [Cgdb-devel] TGDB structures

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

While having a generic list package is helpful, its pretty easy to make
a linked list, just by sticking a 'next' pointer at the end of a struct.
I'm just sayin, is all.

You can still do the tgdb_get_command, if you pass an opaque iterator
around.  Check out the Iterator design pattern (in the book, "Design
Patterns").  Personally, I think the less mucking around inside the tgdb
api, the better. =20

- Peter

On Wed, Sep 17, 2003 at 08:27:16AM -0400, Bob Rossi wrote:
> Ok, well then that settles it. We will not use glib for TGDB. I will
> write up a quick implementation of 'struct tgdb_list'. Then I will
> export that to the front end side. So, all front end writers will have
> to manipulate tgdb_list structures.
>=20
> If anyone can think of anything better, let me know.
>=20
> Hey Peter, do you still like the idea of 'tgdb_get_command()' even
> though we have the list implementation now? I could just return a
> tgdb_list of commands. For some strange reason, I still kind of like the
> tgdb_get_command() function. It avoids the list of list problem. If
> that can be called a problem.
>=20
> A list of commands. Where each command can have a list of breakpoints,
> or a list of frames ...
>=20
> Sometimes I am not sure if these little details even matter :)
>=20
> Bob Rossi
>=20
> On Wed, Sep 17, 2003 at 12:31:16PM +0200, Ronald Landheer-Cieslak wrote:
> > On Tue, Sep 16, 2003 at 06:30:32PM -0400, Bob Rossi wrote:
> > > I was seriously thinking about making TGDB depend on Glib.
> > > What do you guys think?
> > >=20
> > > This is really important since we would be exporting lists of type Gl=
ist
> > > to the front ends? Are there any objections? Or better solutions?
> > IMHO, that would not be a good idea. You'd loose portability for some o=
f=20
> > the platforms cgdb currently works under (including Cygwin, as glib is =
not
> > part of the Cygwin distribution).
> >=20
> > You could, of course, make the dependency optional, but the problem wit=
h=20
> > optional dependencies is that they tend to become maintenance nightmares
> > rather quickly.
> >=20
> > Personally, I'd probably opt for making a light-weight list implementat=
ion
> > if you really need one for tgdb. Lists are not that hard to implement=
=20
> > efficiently.
> >=20
> > Just my opinion, of course, but I would like to avoid cgdb depending on=
=20
> > anything not in the Cygwin distribution, as it would make it a bit hard=
er=20
> > to maintain a cgdb version for Cygwin :|
> >=20
> > rlc
> >=20
> > --=20
> > Television has proved that people will look at anything rather than eac=
h other.
> > 		-- Ann Landers
> >=20
> >=20
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Cgdb-devel mailing list
> > Cgd...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgdb-devel



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

Re: [Cgdb-devel] TGDB structures

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

Ok, well then that settles it. We will not use glib for TGDB. I will
write up a quick implementation of 'struct tgdb_list'. Then I will
export that to the front end side. So, all front end writers will have
to manipulate tgdb_list structures.

If anyone can think of anything better, let me know.

Hey Peter, do you still like the idea of 'tgdb_get_command()' even
though we have the list implementation now? I could just return a
tgdb_list of commands. For some strange reason, I still kind of like the
tgdb_get_command() function. It avoids the list of list problem. If
that can be called a problem.

A list of commands. Where each command can have a list of breakpoints,
or a list of frames ...

Sometimes I am not sure if these little details even matter :)

Bob Rossi

On Wed, Sep 17, 2003 at 12:31:16PM +0200, Ronald Landheer-Cieslak wrote:
> On Tue, Sep 16, 2003 at 06:30:32PM -0400, Bob Rossi wrote:
> > I was seriously thinking about making TGDB depend on Glib.
> > What do you guys think?
> >=20
> > This is really important since we would be exporting lists of type Glist
> > to the front ends? Are there any objections? Or better solutions?
> IMHO, that would not be a good idea. You'd loose portability for some of=
=20
> the platforms cgdb currently works under (including Cygwin, as glib is not
> part of the Cygwin distribution).
>=20
> You could, of course, make the dependency optional, but the problem with=
=20
> optional dependencies is that they tend to become maintenance nightmares
> rather quickly.
>=20
> Personally, I'd probably opt for making a light-weight list implementation
> if you really need one for tgdb. Lists are not that hard to implement=20
> efficiently.
>=20
> Just my opinion, of course, but I would like to avoid cgdb depending on=
=20
> anything not in the Cygwin distribution, as it would make it a bit harder=
=20
> to maintain a cgdb version for Cygwin :|
>=20
> rlc
>=20
> --=20
> Television has proved that people will look at anything rather than each =
other.
> 		-- Ann Landers
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel

Re: [Cgdb-devel] TGDB structures

[Ronald Landheer-C. <bly...@us...>]

On Tue, Sep 16, 2003 at 06:30:32PM -0400, Bob Rossi wrote:
> I was seriously thinking about making TGDB depend on Glib.
> What do you guys think?
> 
> This is really important since we would be exporting lists of type Glist
> to the front ends? Are there any objections? Or better solutions?
IMHO, that would not be a good idea. You'd loose portability for some of 
the platforms cgdb currently works under (including Cygwin, as glib is not
part of the Cygwin distribution).

You could, of course, make the dependency optional, but the problem with 
optional dependencies is that they tend to become maintenance nightmares
rather quickly.

Personally, I'd probably opt for making a light-weight list implementation
if you really need one for tgdb. Lists are not that hard to implement 
efficiently.

Just my opinion, of course, but I would like to avoid cgdb depending on 
anything not in the Cygwin distribution, as it would make it a bit harder 
to maintain a cgdb version for Cygwin :|

rlc

-- 
Television has proved that people will look at anything rather than each other.
		-- Ann Landers

[Cgdb-devel] TGDB structures

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

Hi,

I was seriously thinking about making TGDB depend on Glib.
What do you guys think?

This is really important since we would be exporting lists of type Glist
to the front ends? Are there any objections? Or better solutions?

Bob Rossi

Re: [Cgdb-devel] CGDB 1.0 Proposal again

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

Cool idea!

On Tue, 16 Sep 2003, Bob Rossi wrote:

:Hi,
:
:Mike, this pertains particularly to you. I was thinking a nice 1.0
:feature would be to write the contents of a window to a file ( :w ).
:This would be really usefull when trying to print the stack. Or trying
:to print some data that TGDB can give the front end.
:
:It could just write it to a text file. Nothing complicated.
:
:Bob Rossi
:

[Cgdb-devel] CGDB 1.0 Proposal again

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

Hi,

Mike, this pertains particularly to you. I was thinking a nice 1.0
feature would be to write the contents of a window to a file ( :w ).
This would be really usefull when trying to print the stack. Or trying
to print some data that TGDB can give the front end.

It could just write it to a text file. Nothing complicated.

Bob Rossi

[Cgdb-devel] TGDB detects when GDB goes psycho!

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

Hi,

=46rom now on, TGDB will return TGDB_QUIT_NORMAL when it thinks that GDB
has quit normally. It will return TGDB_QUIT_ABNORMAL when it thinks that
GDB crashed or dies unexpectedly.

I don't know if someone wants to work on CGDB to handle these cases
appropriately. Currently, CGDB quits either way. It would be cool if it
printed a message to the user, telling them that GDB died. This way we
can tell the difference between when CGDB crashes and GDB crashes.

Bob Rossi

Re: [Cgdb-devel] TGDB return structures

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

Woooo, I really like that idea. Thanks Peter. I'll go down that path and
see what it yields!

Bob Rossi

On Mon, Sep 15, 2003 at 09:03:13AM -0400, Peter Kovacs wrote:
> If the problem is, retreiving a list of actions/info from tgdb, why not
> just call a function in a loop until it returns NULL?  (Or something
> like that).
>=20
>     action =3D tgdb_first_action( tgdb );
>     do=20
>     {
>         ... /* process action */
>     }
>     while( action =3D tgdb_next_action( tgdb, action ) );
>=20
> You might be able to keep the queue struct in the tgdb side of things,
> and only export the parts that are needed for the action side.
>=20
> Does that even make sense?  Its early, and I'm home sick. :(
>=20
> - Peter
>=20
> On Sun, Sep 14, 2003 at 09:07:22PM -0400, Bob Rossi wrote:
> > Hi All,
> >=20
> > I am struggling with a particular issue. I feel that this issue is
> > *really* important to the future of TGDB and I can not come up with a
> > reasonable solution.
> >=20
> > Currently, TGDB only returns
> > data to the front end as a return value of the function
> > tgdb_recv_debugger_data. The prototype is below.
> >=20
> > size_t tgdb_recv_debugger_data ( struct tgdb *tgdb, char *buf, size_t n,
> > struct queue *q );
> >=20
> > The return value q, is basically a list of commands that TGDB has
> > discovered from parsing the output of GDB. Stuff like TGDB_BREAKPOINTS,
> > ...
> >=20
> > The problem is, I don't want to export the 'struct queue' data structure
> > because its a ridiculous data structure to 'show the world'. I don't
> > really want front end writers to have to learn how to use the silly data
> > structure. The struct was invented to be used for TGDB's internal, it
> > only was exported to the front end to save time.
> >=20
> > What do you guys think a good way of returning commands to the front en=
d is?
> >=20
> >  1. callbacks=20
> >     This isn't really that much different, except I could call function=
s that=20
> >     take a specific data structure like ( struct tgdb_breakpoint ).
> >     The downside is that the client will have to register a lot of
> >     callbacks, and some GUI's don't fit the callback method well.
> >     Especially with multiple contexts.
> >=20
> >     I don't really like this alternative. It seems like some GUI's won't
> >     fit this model well without modifing TGDB.
> >=20
> >  2. keep the data structure in the return value.
> >     I will need to get a 'real' data structure like glib's glist or
> >     something.
> >=20
> >     I don't really like this alternative either :)
> >=20
> > Well, what do you guys think, any ideas?
> >=20
> > Bob Rossi
>=20
>=20
>=20
> --=20
> Peter D. Kovacs <pe...@ko...>

Re: [Cgdb-devel] TGDB return structures

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

If the problem is, retreiving a list of actions/info from tgdb, why not
just call a function in a loop until it returns NULL?  (Or something
like that).

    action =3D tgdb_first_action( tgdb );
    do=20
    {
        ... /* process action */
    }
    while( action =3D tgdb_next_action( tgdb, action ) );

You might be able to keep the queue struct in the tgdb side of things,
and only export the parts that are needed for the action side.

Does that even make sense?  Its early, and I'm home sick. :(

- Peter

On Sun, Sep 14, 2003 at 09:07:22PM -0400, Bob Rossi wrote:
> Hi All,
>=20
> I am struggling with a particular issue. I feel that this issue is
> *really* important to the future of TGDB and I can not come up with a
> reasonable solution.
>=20
> Currently, TGDB only returns
> data to the front end as a return value of the function
> tgdb_recv_debugger_data. The prototype is below.
>=20
> size_t tgdb_recv_debugger_data ( struct tgdb *tgdb, char *buf, size_t n,
> struct queue *q );
>=20
> The return value q, is basically a list of commands that TGDB has
> discovered from parsing the output of GDB. Stuff like TGDB_BREAKPOINTS,
> ...
>=20
> The problem is, I don't want to export the 'struct queue' data structure
> because its a ridiculous data structure to 'show the world'. I don't
> really want front end writers to have to learn how to use the silly data
> structure. The struct was invented to be used for TGDB's internal, it
> only was exported to the front end to save time.
>=20
> What do you guys think a good way of returning commands to the front end =
is?
>=20
>  1. callbacks=20
>     This isn't really that much different, except I could call functions =
that=20
>     take a specific data structure like ( struct tgdb_breakpoint ).
>     The downside is that the client will have to register a lot of
>     callbacks, and some GUI's don't fit the callback method well.
>     Especially with multiple contexts.
>=20
>     I don't really like this alternative. It seems like some GUI's won't
>     fit this model well without modifing TGDB.
>=20
>  2. keep the data structure in the return value.
>     I will need to get a 'real' data structure like glib's glist or
>     something.
>=20
>     I don't really like this alternative either :)
>=20
> Well, what do you guys think, any ideas?
>=20
> Bob Rossi



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

[Cgdb-devel] TGDB return structures

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

Hi All,

I am struggling with a particular issue. I feel that this issue is
*really* important to the future of TGDB and I can not come up with a
reasonable solution.

Currently, TGDB only returns
data to the front end as a return value of the function
tgdb_recv_debugger_data. The prototype is below.

size_t tgdb_recv_debugger_data ( struct tgdb *tgdb, char *buf, size_t n,
struct queue *q );

The return value q, is basically a list of commands that TGDB has
discovered from parsing the output of GDB. Stuff like TGDB_BREAKPOINTS,
=2E..

The problem is, I don't want to export the 'struct queue' data structure
because its a ridiculous data structure to 'show the world'. I don't
really want front end writers to have to learn how to use the silly data
structure. The struct was invented to be used for TGDB's internal, it
only was exported to the front end to save time.

What do you guys think a good way of returning commands to the front end is?

 1. callbacks=20
    This isn't really that much different, except I could call functions th=
at=20
    take a specific data structure like ( struct tgdb_breakpoint ).
    The downside is that the client will have to register a lot of
    callbacks, and some GUI's don't fit the callback method well.
    Especially with multiple contexts.

    I don't really like this alternative. It seems like some GUI's won't
    fit this model well without modifing TGDB.

 2. keep the data structure in the return value.
    I will need to get a 'real' data structure like glib's glist or
    something.

    I don't really like this alternative either :)

Well, what do you guys think, any ideas?

Bob Rossi

Re: [Cgdb-devel] TGDB architecture

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

> > > What is the recovery when gdb goes to debugger heaven ?
> >=20
> > TGDB has no problem when GDB crashes. I think that what you mean here,
> > right?
> >=20
> > Currently, it return TGDB_QUIT to the front end, and then CGDB just
> > shuts down. It appears that CGDB doesn't work properly but thats just
> > what we decided to do for now. The reason is because TGDB just reads a
> > 'EOF' when TGDB dies, and currently it doesn't know if the EOF is
> > because of normal or abnormal termination.
>=20
> Couldn't we check the return val of a waitpid call when we receive the
> EOF?  That's the usual manner to check to see if a program exited
> abnormally.

Yeah, that seems like a good idea. Then I could return things like
TGDB_QUIT_NORMAL and TGDB_QUIT_ABNORMAL with an error code or something.
Unfortunatly, I have a feeling this will be somewhat non-portable. I'll
look into it.

Bob Rossi

Re: [Cgdb-devel] TGDB architecture

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

On Fri, Sep 12, 2003 at 07:41:19PM -0400, Bob Rossi wrote:
> I have made a significant effort to make TGDB context driven over the
> last several months. That seems to be done now. However, since TGDB was
> not designed with either of these goals in mind, there are places in the
> code were there are static variables defined in functions. Thus, it is
> probably not thread safe. These things are probably easy to solve.

I'm pretty sure this is all that's necessary.  Eliminate all static
variables in functions so that they are fully reentrant (can be called
interrupted and called again with no problems).  The stuff you've done
to convert things to the context driven interface is a huge step in the
right direction. =20

Keep in mind that, in general, GUI programs are single threaded.  Right
now, the only major hang up with a GUI program using tgdb is accessing
tgdbs file descriptors.  We may need some more work in this area (and
really, could probably only find all the bugs if somebody actually
writes a GUI based on tgdb).

>=20
> > What is the recovery when gdb goes to debugger heaven ?
>=20
> TGDB has no problem when GDB crashes. I think that what you mean here,
> right?
>=20
> Currently, it return TGDB_QUIT to the front end, and then CGDB just
> shuts down. It appears that CGDB doesn't work properly but thats just
> what we decided to do for now. The reason is because TGDB just reads a
> 'EOF' when TGDB dies, and currently it doesn't know if the EOF is
> because of normal or abnormal termination.

Couldn't we check the return val of a waitpid call when we receive the
EOF?  That's the usual manner to check to see if a program exited
abnormally.

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

Re: [Cgdb-devel] TGDB architecture

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

On Fri, Sep 12, 2003 at 11:35:21AM -0400, Alain Magloire wrote:
> Bonjour
>=20
> 	hum ... this is more of a test, to check subscribtion 8-)

Yay, it works!

>=20
> Is part of TGDB desing, support for threaded clients ?

Ok, TGDB was initially not designed to handle threaded clients. It was
also initially not designed to be context driven.=20

I have made a significant effort to make TGDB context driven over the
last several months. That seems to be done now. However, since TGDB was
not designed with either of these goals in mind, there are places in the
code were there are static variables defined in functions. Thus, it is
probably not thread safe. These things are probably easy to solve.

There are several issues in mind. TGDB will probably never be thread
safe to the point where a front end calls the same function on the same
context together. There are no mutex's in TGDB to stop such things.
However, if the front end calls the same function with 2 different
contexts at the same time, that should be fine.

Personally I have never written a threaded program, I have only read and
studied about them ... do you think what I am saying here is going in=20
the right direction?

I am not sure exactly what it would mean to make TGDB fully thread safe
for clients.

> What is the recovery when gdb goes to debugger heaven ?

TGDB has no problem when GDB crashes. I think that what you mean here,
right?

Currently, it return TGDB_QUIT to the front end, and then CGDB just
shuts down. It appears that CGDB doesn't work properly but thats just
what we decided to do for now. The reason is because TGDB just reads a
'EOF' when TGDB dies, and currently it doesn't know if the EOF is
because of normal or abnormal termination.

Do you have any suggestions on making this better?

Bob Rossi