Thread: [Cgdb-devel] TGDB architecture

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Bonjour

	hum ... this is more of a test, to check subscribtion 8-)

Is part of TGDB desing, support for threaded clients ?
What is the recovery when gdb goes to debugger heaven ?

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

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...>

> > > 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

> 
> 
> --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.

> 
> 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.

> 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

> 
> 
> --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 .

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...>

On Wed, 17 Sep 2003, Peter Kovacs wrote:

: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.

I think the flawed assumption here is that the GUI has to hang if 
GDB hangs.  TGDB returns a file descriptor to the GUI, and the GUI 
is responsible for waking up when that file descriptor has data 
waiting.  That does not mean that the GUI needs to do a blocking 
select.  Qt, for example, can wait on a file descriptor as part of 
its main input loop, so the program is still responsive while 
waiting for input from the descriptor.

Secondly, if a command is issued to GDB, such as a 'next' command, 
and GDB is taking a while to execute, that's fine.  The GUI does not 
need to wait until the command finishes to respond to the user (CGDB 
is an example of this, it does not freeze while GDB is working).  
Basically what I'm saying is it is up to the GUI author to determine 
how to properly handle these situations, not libtgdb.

Mike

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...>

On Wed, Sep 17, 2003 at 04:06:15PM -0400, Peter Kovacs wrote:
> 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 applicati=
on) 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
>=20
> Sorry, I read this too quickly before.  The idea of sending a SIGINT
> still works.=20
>=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.
>=20

I agree. The only thing that the GUI should know is when GDB is
blocking. We could write a non-blocking function call like
tgdb_is_debugger_running() to let the front end know if GDB is running.
In this case, the front end could display an hour glass or something.

That would cause polling though.=20

Maybe it would be better for TGDB to return the commands
TGDB_STARTED_COMAND and TGDB_FINISHED_COMMAND or
something to let the front end know the state of the debugger.

Bob Rossi

Thread: [Cgdb-devel] TGDB architecture

cgdb-devel