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

[Cgdb-devel] Cgdb port for Cygwin

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

I've made the first set of changes to my local sandbox to allow out-of-tree 
building and am about to commit them (or rather: will commit them tomorow 
morning) to the cygwin package's branch. Are there any objections against me
removing the generated files (Makefile.in, configure, etc.) from the branch?
They tend to bloat the CVS contents and, for the moment, do not exactly 
reflect my changes because they're re-created with a different set of 
Autotools than I will use to make the final package.. (IMHO, no generated
files should exist in CVS anyway..).

Of course, when merging any changes I make into HEAD, you can keep the (then
again re-generated) files if you want :)

rlc

-- 
You're out of memory

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

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

I'm about to start porting cgdb 0.4.0 to Cygwin. If you want me to work 
directly on a CVS branch, now would be a great time to set something along
these lines up :)

rlc

On Tue, Oct 28, 2003 at 11:13:27PM -0500, Bob Rossi wrote:
> On Tue, Oct 28, 2003 at 03:11:09PM +0100, Ronald Landheer-Cieslak wrote:
> > On Mon, Oct 27, 2003 at 07:08:41PM -0500, Bob Rossi wrote:
> > > How important is it to you to apply this patch to CGDB before I release
> > > .4.0? Could we settle these issues after the release?
> > That would basically mean you have another slightly broken release, but I
> > don't think that will make a real difference. If you want, if you set a
> > release tag on cgdb version 4.0 and give me write access to a Cygwin release
> > branch, I can do the necessary changes directly in CVS on the branch. 
> > My SF username is "blytkerchan".
> 
> Ok, I will set something up along these lines. 
> 
> Bob Rossi



-- 
That's the true harbinger of spring, not crocuses or swallows
returning to Capistrano, but the sound of a bat on a ball.
		-- Bill Veeck

Re: [Cgdb-devel] 0.4.0 debian package

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

On Thu, Oct 30, 2003 at 10:15:14AM -0500, Bob Rossi wrote:
> Ok, I will remove those 3 files from the distribution.
> Is there a trivial way to do this? or will I have to use a hook of some
> sort? Currently, I am doing this
>=20
> dist-hook:
>     rm -rf `find $(distdir) -name CVS`
>=20
> should I modify this line to also remove the files mentioned above?
> Or is there a better way?

looks cool to me

cu  robert

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

Re: [Cgdb-devel] 0.4.0 debian package

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

On Thu, Oct 30, 2003 at 03:38:58PM +0100, Robert Lemmen wrote:
> On Wed, Oct 29, 2003 at 03:44:11PM -0500, Bob Rossi wrote:
> >     I will make it a goal to have a documentation system in place for
> >     version .5.0. Do you have any suggestions? What do other packages
> >     you work with do to solve this problem?
>=20
> i think you need a manual page that gets one started and a proper manual
> with a reference section and a tutorial one that has examples. most
> packages do the "real"manual with some kind of sgml so they can create
> html and/or pdf/postscript from it.=20

I agree. I will look into this.

>=20
> >     I'll be the first one to tell you, I don't know much about autoconf.
> >     If you have suggestions on files that I should take it, let me know.
> >     My original intention was to allow people to check out CGDB from
> >     CVS with out having to have automake/autoconf installed. If I
> >     remove these files from CVS, will people still be able to build out
> >     of CVS without having automake/autoconf installed?
>=20
> config.log, .status and .cache are not generated by autoconf, but by the
> generated configure and are very machine-dependent. they should not be
> distributed. basically you want to distribute your sources, Makefile.in
> (and other .in used by configure) files and the configure script. if you
> want you can also distribute the automake/autoconf files (like
> Makefile.am etc) so people *can* rebuild the configure script if they
> feel like it, but i don't think you should. people who want to do that
> should run a cvs snapshot anyway.

Ok, I will remove those 3 files from the distribution.
Is there a trivial way to do this? or will I have to use a hook of some
sort? Currently, I am doing this

dist-hook:
    rm -rf `find $(distdir) -name CVS`

should I modify this line to also remove the files mentioned above?
Or is there a better way?

Thanks,
Bob Rossi

Re: [Cgdb-devel] 0.4.0 debian package

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

On Wed, Oct 29, 2003 at 03:44:11PM -0500, Bob Rossi wrote:
>     I will make it a goal to have a documentation system in place for
>     version .5.0. Do you have any suggestions? What do other packages
>     you work with do to solve this problem?

i think you need a manual page that gets one started and a proper manual
with a reference section and a tutorial one that has examples. most
packages do the "real"manual with some kind of sgml so they can create
html and/or pdf/postscript from it.=20

>     I'll be the first one to tell you, I don't know much about autoconf.
>     If you have suggestions on files that I should take it, let me know.
>     My original intention was to allow people to check out CGDB from
>     CVS with out having to have automake/autoconf installed. If I
>     remove these files from CVS, will people still be able to build out
>     of CVS without having automake/autoconf installed?

config.log, .status and .cache are not generated by autoconf, but by the
generated configure and are very machine-dependent. they should not be
distributed. basically you want to distribute your sources, Makefile.in
(and other .in used by configure) files and the configure script. if you
want you can also distribute the automake/autoconf files (like
Makefile.am etc) so people *can* rebuild the configure script if they
feel like it, but i don't think you should. people who want to do that
should run a cvs snapshot anyway.

cu  robert

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

Re: [Cgdb-devel] 0.4.0 debian package

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

> i just built debian packages for 0.4.0 which will show up in unstable in
> a few days.=20

   Great! Thanks for the quick debian release!

> i have questions however:
> - don't you guys think it would be good to include a man page? i have
>   hacked one together for debian but it isn't really good. and other
>   people deserve one too...

    Yes, I think it would be good to include a man page. The problem
    is, we need a general purpose documentation solution, not just a man
    page.

    Currently, we have the README file. Which gets put into the CGDB
    executable. The user can see it by doing :help. However, we also
    need to support a webpage and a man page.

    I will make it a goal to have a documentation system in place for
    version .5.0. Do you have any suggestions? What do other packages
    you work with do to solve this problem?

> - what is that tgdb/testsuite dir? can't figure out what that is good
>   for

    The testsuite tests the tgdb_driver binary. This binary is a simple
    command line interface that links with TGDB. It is what I use to
    debug/test TGDB.

    1. cd into the directory.
    2. ./configure
    3. make
    4. make check

    It will run the testsuite. It is the beggining of some tests to
    check the functionality of TGDB. So far there are not that many
    tests, but I plan to fix it up as TGDB becomes more stable.

    You need to have dejagnu installed to run the testsuite.
> - in that directory you ship config.log and config.status files, which
>   you should not do imho since these might mess up a build on a
>   different computer

    I'll be the first one to tell you, I don't know much about autoconf.
    If you have suggestions on files that I should take it, let me know.
    My original intention was to allow people to check out CGDB from
    CVS with out having to have automake/autoconf installed. If I
    remove these files from CVS, will people still be able to build out
    of CVS without having automake/autoconf installed?

Thanks,
Bob Rossi

[Cgdb-devel] 0.4.0 debian package

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

hi everyone,

i just built debian packages for 0.4.0 which will show up in unstable in
a few days. i have questions however:
- don't you guys think it would be good to include a man page? i have
  hacked one together for debian but it isn't really good. and other
  people deserve one too...
- what is that tgdb/testsuite dir? can't figure out what that is good
  for
- in that directory you ship config.log and config.status files, which
  you should not do imho since these might mess up a build on a
  different computer

cu  robert =20

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

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

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

On Tue, Oct 28, 2003 at 03:11:09PM +0100, Ronald Landheer-Cieslak wrote:
> On Mon, Oct 27, 2003 at 07:08:41PM -0500, Bob Rossi wrote:
> > How important is it to you to apply this patch to CGDB before I release
> > .4.0? Could we settle these issues after the release?
> That would basically mean you have another slightly broken release, but I
> don't think that will make a real difference. If you want, if you set a
> release tag on cgdb version 4.0 and give me write access to a Cygwin rele=
ase
> branch, I can do the necessary changes directly in CVS on the branch.=20
> My SF username is "blytkerchan".

Ok, I will set something up along these lines.=20

Bob Rossi

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

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

On Mon, Oct 27, 2003 at 07:08:41PM -0500, Bob Rossi wrote:
> How important is it to you to apply this patch to CGDB before I release
> .4.0? Could we settle these issues after the release?
That would basically mean you have another slightly broken release, but I
don't think that will make a real difference. If you want, if you set a
release tag on cgdb version 4.0 and give me write access to a Cygwin release
branch, I can do the necessary changes directly in CVS on the branch. 
My SF username is "blytkerchan".

rlc

-- 
Parkinson's Law:  Work expands to fill the time alloted it.

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

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

On Mon, Oct 27, 2003 at 02:30:59PM +0100, Ronald Landheer-Cieslak wrote:
> On Thu, Oct 23, 2003 at 09:59:10PM -0400, Bob Rossi wrote:
> > The problem is, I wrote the Makefile.am's without really knowing
> > anything about autoconf/automake. I am seeing that you basically changed
> > top_srcdir with top_builddir. What's the difference? From the autoconf
> > page I see
> > top_srcdir: The relative path to the top-level source code directory for
> > the package.
> > top_builddir: The relative path to the top-level of the current build
> > tree.
> > I don't really know how this relates to cgdb or why you changed it.
> If you want to do an out-of-directory build (i.e. ../cgdb-src/configure &=
& make)
> you need to point to the right directory - the one the files are actually=
 in.
> Out-of-directory builds especially work nicely with read-only source trees
> and symlinked source trees. The latter is often used when creating patche=
s=20
> relative to a read-only (already-released/canonical) source tree: you unt=
ar
> the source tree, make it read-only, symlink-tree it (the script can be fo=
und
> in the gcc sources and comes in really handy) and do an out-of-tree build
> on the symlink tree. You can then run diff between the r/o source tree an=
d=20
> the r/w symlink tree after you've made changes to the files in the symlink
> tree (unlinking every file you change).
>=20
> When I made the patch, I was working with an out-of-tree build, as is nor=
mal
> for Cygwin packages, and as I normally do for my own builds for the reaso=
ns
> described above..

Ok, This is really neat. I didn't know people did this!

> > I noticed that you also changed the noinst_bin_PROGRAMS and
> > noinst_bindir to noinst_PROGRAMS. This doesn't work so well for me since
> > programs no longer install into the cgdb/progs directory. What would you
> > recommend for this?
> AFAICT, you don't actually want to install those files (with make install=
)=20
> do you? If so, you can have them constructed in-place (with noinst_PROGRA=
MS)
> and use the $(builddir) variable to find out where they are.
>=20
> I don't quite remember what the problems were with the noinst_bindir setu=
p,
> but there was a reason why I removed it.. I'd have to try to find out. In=
=20
> any case, after removing it the build I did worked w/o any problems.

I do want to put all of the misc programs into 1 directory. If we could
figure out how to do that, that would be cool.
>=20
> > I applied your patch, and it builds in the tree properly. What is the
> > command that you were using to build out of the tree? I would like to
> > make sure they both work before I commit the patch.
> >From the root of your work directory:
> $ tar xzvf cgdb-version-src.tar.gz
> $ mkdir cgdb-build
> $ cd cgdb-build
> $ ../cgdb-version/configure --prefix=3D/usr
> $ make
> $ make install DESTDIR=3D`pwd`/../cgdb-install

I tried this and noticed that the compiler couldn't find all of the
headers, ... maybe you patched some other stuff also, or my environment
is somehow different.

How important is it to you to apply this patch to CGDB before I release
=2E4.0? Could we settle these issues after the release?

Bob Rossi

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

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

On Thu, Oct 23, 2003 at 09:59:10PM -0400, Bob Rossi wrote:
> The problem is, I wrote the Makefile.am's without really knowing
> anything about autoconf/automake. I am seeing that you basically changed
> top_srcdir with top_builddir. What's the difference? From the autoconf
> page I see
> top_srcdir: The relative path to the top-level source code directory for
> the package.
> top_builddir: The relative path to the top-level of the current build
> tree.
> I don't really know how this relates to cgdb or why you changed it.
If you want to do an out-of-directory build (i.e. ../cgdb-src/configure && make)
you need to point to the right directory - the one the files are actually in.
Out-of-directory builds especially work nicely with read-only source trees
and symlinked source trees. The latter is often used when creating patches 
relative to a read-only (already-released/canonical) source tree: you untar
the source tree, make it read-only, symlink-tree it (the script can be found
in the gcc sources and comes in really handy) and do an out-of-tree build
on the symlink tree. You can then run diff between the r/o source tree and 
the r/w symlink tree after you've made changes to the files in the symlink
tree (unlinking every file you change).

When I made the patch, I was working with an out-of-tree build, as is normal
for Cygwin packages, and as I normally do for my own builds for the reasons
described above..

> I noticed that you also changed the noinst_bin_PROGRAMS and
> noinst_bindir to noinst_PROGRAMS. This doesn't work so well for me since
> programs no longer install into the cgdb/progs directory. What would you
> recommend for this?
AFAICT, you don't actually want to install those files (with make install) 
do you? If so, you can have them constructed in-place (with noinst_PROGRAMS)
and use the $(builddir) variable to find out where they are.

I don't quite remember what the problems were with the noinst_bindir setup,
but there was a reason why I removed it.. I'd have to try to find out. In 
any case, after removing it the build I did worked w/o any problems.

> I applied your patch, and it builds in the tree properly. What is the
> command that you were using to build out of the tree? I would like to
> make sure they both work before I commit the patch.
From the root of your work directory:
$ tar xzvf cgdb-version-src.tar.gz
$ mkdir cgdb-build
$ cd cgdb-build
$ ../cgdb-version/configure --prefix=/usr
$ make
$ make install DESTDIR=`pwd`/../cgdb-install

HTH

rlc

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

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

> Some of the files are generated, but the useful (and non-transient) part =
of the
> patch is in the Makefile.am files.
> A patch of only those files is now available where the old one was:
> 58bd52d3df08977056b1d18dbe3cc7b7 *cgdb-0.3.4-1.patch
> http://rlc.unsane.co.uk/cgdb-0.3.4-1.patch
>=20
> The old patch also patches configure.in, but you might want to look at th=
at
> a bit closer, as I only simplified it a bit, and adapted it to by dev=20
> environment - there are no changes in it that you will really need.
> (Sorry for the confusion)

Hi Ronald,

I am interested in releasing cgdb-0.4.0. I am ready to look at applying
the patch above.

The problem is, I wrote the Makefile.am's without really knowing
anything about autoconf/automake. I am seeing that you basically changed
top_srcdir with top_builddir. What's the difference? From the autoconf
page I see
top_srcdir: The relative path to the top-level source code directory for
the package.
top_builddir: The relative path to the top-level of the current build
tree.
I don't really know how this relates to cgdb or why you changed it.

I noticed that you also changed the noinst_bin_PROGRAMS and
noinst_bindir to noinst_PROGRAMS. This doesn't work so well for me since
programs no longer install into the cgdb/progs directory. What would you
recommend for this?

I applied your patch, and it builds in the tree properly. What is the
command that you were using to build out of the tree? I would like to
make sure they both work before I commit the patch.

Thanks,
Bob Rossi

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

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

> Some of the files are generated, but the useful (and non-transient) part of the
> patch is in the Makefile.am files.
> A patch of only those files is now available where the old one was:
> 58bd52d3df08977056b1d18dbe3cc7b7 *cgdb-0.3.4-1.patch
> http://rlc.unsane.co.uk/cgdb-0.3.4-1.patch

Hi Ronald,

I am interested in releasing cgdb-0.4.0. I am ready to look at applying
the patch above.

The problem is, I wrote the Makefile.am's without really knowing
anything about autoconf/automake. I am seeing that you basically changed
top_srcdir with top_builddir. What's the difference? From the autoconf
page I see
top_srcdir: The relative path to the top-level source code directory for
the package.
top_builddir: The relative path to the top-level of the current build
tree.
I don't really know how this relates to cgdb or why you changed it.

I noticed that you also changed the noinst_bin_PROGRAMS and
noinst_bindir to noinst_PROGRAMS. This doesn't work so well for me since
programs no longer install into the cgdb/progs directory. What would you
recommend for this?

I applied your patch, and it builds in the tree properly. What is the
command that you were using to build out of the tree? I would like to
make sure they both work before I commit the patch.

Thanks,
Bob Rossi

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

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

> Some of the files are generated, but the useful (and non-transient) part of the
> patch is in the Makefile.am files.
> A patch of only those files is now available where the old one was:
> 58bd52d3df08977056b1d18dbe3cc7b7 *cgdb-0.3.4-1.patch
> http://rlc.unsane.co.uk/cgdb-0.3.4-1.patch

Hi Ronald,

I am interested in releasing cgdb-0.4.0. I am ready to look at applying
the patch above.

The problem is, I wrote the Makefile.am's without really knowing
anything about autoconf/automake. I am seeing that you basically changed
top_srcdir with top_builddir. What's the difference? From the autoconf
page I see
top_srcdir: The relative path to the top-level source code directory for
the package.
top_builddir: The relative path to the top-level of the current build
tree.
I don't really know how this relates to cgdb or why you changed it.

I noticed that you also changed the noinst_bin_PROGRAMS and
noinst_bindir to noinst_PROGRAMS. This doesn't work so well for me since
programs no longer install into the cgdb/progs directory. What would you
recommend for this?

I applied your patch, and it builds in the tree properly. What is the
command that you were using to build out of the tree? I would like to
make sure they both work before I commit the patch.

Thanks,
Bob Rossi

[Cgdb-devel] Test message

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

Please disregard this message

[Cgdb-devel] TGDB new file tgdb_client_architecture

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

Hi,

I just finished up something thats been long over due. I added the file
tgdb_client_architecture.h and tgdb_client_architecture.c.

This is the interface that TGDB uses to communicate with the lower level
debugger/protocol implementations. Basically, TGDB talks to this
interface and all client implementations ( annotate_two,gdbmi) will have
to implement all of the functions and fill out an entry in the structure
'tgdb_client_debugger_interfaces'.

With this addition, TGDB has clearly defined its borders. It has tgdb.h
and tgdb_types.h to interface with front ends and
tgdb_client_interface.h to allow TGDB to interface with all of the
subsystems.

Alain, it would be great if you would be interested in implementing the
MI interface with me. If you have any ideas/suggestions let me know.

Bob Rossi

[Cgdb-devel] CGDB 1.0 Proposal idea

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

Hi,

I think another great small feature would be to have CGDB open a file at
the last spot it was ( if the user opened the file via the file dialog ).

Mike, are you keeping  track of the small feature requests added for
1.0?

Bob Rossi

Re: [Cgdb-devel] TGDB tgdb_list interface

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

> > Hi,
> >=20
> > Could anyone critique the interface for tgdb_list that I am proposing?
> >=20
> > struct tgdb_list;
> > struct tgdb_list_iterator;
> >=20
> > typedef void (*item_func)(void *item);
> >=20
> > struct tgdb_list *tgdb_list_init ( void );
> >=20
> > void tgdb_list_append ( struct tgdb_list *tlist, void *item );
> > void tgdb_list_prepend ( struct tgdb_list *tlist, void *item );
> > void tgdb_list_insert_after ( struct tgdb_list_iterator *tlisti, void *=
item );
> > void tgdb_list_insert_before ( struct tgdb_list_iterator *tlisti, void =
*item );
> > void tgdb_list_foreach ( struct tgdb_list *tlist, item_func func );
>=20
> Could you return int when something go wrong, say malloc() fails
> or tlist =3D=3D NULL or item =3D=3D NULL.  In the event of some bad karma,
> I do not see at first look how you pass the information up.

Yes, I will do that. Thanks.

>=20
> Why is (void * item), since it seems, at least at first look, that the st=
ruct tgdb_list
> is manipulating iterators (struct tgdb_list_iterator *)=20

The 'void* item' parameter, is the data to insert into the list.

Bob Rossi

Re: [Cgdb-devel] TGDB tgdb_list interface

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

> 
> 
> --82I3+IH0IqGh5yIs
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> Hi,
> 
> Could anyone critique the interface for tgdb_list that I am proposing?
> This is what I came up with.
> 
> Basically, it will be a double linked list. You can get back an iterator
> into the list. You can insert before or after the iterator. The front
> end writers will only use it to traverse the list. The iterators have
> next,previous functionality.
> 
> What does everyone think?
> 
> 
> #ifndef __TGDB_LIST_H__
> #define __TGDB_LIST_H__
> 
> #if HAVE_CONFIG_H
> #include "config.h"
> #endif /* HAVE_CONFIG_H */
> 
> struct tgdb_list;
> struct tgdb_list_iterator;
> 
> typedef void (*item_func)(void *item);
> 
> struct tgdb_list *tgdb_list_init ( void );
> 
> void tgdb_list_append ( struct tgdb_list *tlist, void *item );
> void tgdb_list_prepend ( struct tgdb_list *tlist, void *item );
> void tgdb_list_insert_after ( struct tgdb_list_iterator *tlisti, void *item );
> void tgdb_list_insert_before ( struct tgdb_list_iterator *tlisti, void *item );
> void tgdb_list_foreach ( struct tgdb_list *tlist, item_func func );

Could you return int when something go wrong, say malloc() fails
or tlist == NULL or item == NULL.  In the event of some bad karma,
I do not see at first look how you pass the information up.

Why is (void * item), since it seems, at least at first look, that the struct tgdb_list
is manipulating iterators (struct tgdb_list_iterator *) 

> void tgdb_list_free ( struct tgdb_list *tlist, item_func func );
> int tgdb_list_size ( struct tgdb_list *tlist );
> struct tgdb_list_iterator *tgdb_list_get_first ( struct tgdb_list *tlist );
> struct tgdb_list_iterator *tgdb_list_get_last ( struct tgdb_list *tlist );
> struct tgdb_list_iterator *tgdb_list_next ( struct tgdb_list_iterator *tlisti );
> struct tgdb_list_iterator *tgdb_list_previous ( struct tgdb_list_iterator * tlisti );
> void *tgdb_get_item ( struct tgdb_list_iterator *tlisti );


Later,

Re: [Cgdb-devel] TGDB tgdb_list interface

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

You don't really say, but does 'struct tgdb_list' keep a head, tail
pointer, as well as other bits of info like count, etc?  (Actually,
looking at your API again it doesn't look like it).

It seems fine, but I'm reserving judgement until I see the
implementation.  You should also make a note in the documentation that
append, prepend will potentially invalidate any iterators that you have.

- Peter

> Hi,
>=20
> Could anyone critique the interface for tgdb_list that I am proposing?
> This is what I came up with.
>=20
> Basically, it will be a double linked list. You can get back an iterator
> into the list. You can insert before or after the iterator. The front
> end writers will only use it to traverse the list. The iterators have
> next,previous functionality.
>=20
> What does everyone think?
>=20
>=20
> #ifndef __TGDB_LIST_H__
> #define __TGDB_LIST_H__
>=20
> #if HAVE_CONFIG_H
> #include "config.h"
> #endif /* HAVE_CONFIG_H */
>=20
> struct tgdb_list;
> struct tgdb_list_iterator;
>=20
> typedef void (*item_func)(void *item);
>=20
> /*=20
>  * Initializes a new empty list.
>  *=20
>  * Returns
>  *    The new list.
>  */
> struct tgdb_list *tgdb_list_init ( void );
>=20
> /*=20
>  * Appends item to the end of the list.
>  *=20
>  * tlist
>  *    The list to append an item to.
>  *
>  * item
>  *    The item to add to the list
>  */
> void tgdb_list_append ( struct tgdb_list *tlist, void *item );
>=20
> /*=20
>  * Prepends item to the beggining of the list.
>  *=20
>  * tlist
>  *    The list to prepend an item to.
>  *
>  * item
>  *    The item to add to the list
>  */
> void tgdb_list_prepend ( struct tgdb_list *tlist, void *item );
>=20
> /*=20
>  * appends the item after the position of the iterator.
>  *=20
>  * tlisti
>  *    The iterator to insert after.
>  *
>  * item
>  *    The item to add to the list
>  */
> void tgdb_list_insert_after ( struct tgdb_list_iterator *tlisti, void *it=
em );
>=20
> /*=20
>  * prepands the item before the position of the iterator.
>  *=20
>  * tlisti
>  *    The iterator to insert before.
>  *
>  * item
>  *    The item to add to the list
>  */
> void tgdb_list_insert_before ( struct tgdb_list_iterator *tlisti, void *i=
tem );
>=20
> /* Traversing the tree */
>=20
> /*=20
>  * Traverses each item in the list, passing each element to func
>  *
>  * tlist
>  *    The list to traverse
>  *
>  * func
>  *    The function to call on each item
>  */
> void tgdb_list_foreach ( struct tgdb_list *tlist, item_func func );
>=20
> /* Freeing the tree */
>=20
> /*=20
>  * Free's list item by calling func on each element
>  * This function is different because it will free the list as it=20
>  * traverses the list.
>  *
>  * tlist
>  *    The list to free
>  *
>  * func
>  *    The function to free an item
>  */
> void tgdb_list_free ( struct tgdb_list *tlist, item_func func );
>=20
> /*=20
>  * Gets the size of the list.
>  *
>  * tlist
>  *    The list context to get the size of.
>  *
>  * Returns
>  * 	  The size of the list, 0 if empty.
>  */
> int tgdb_list_size ( struct tgdb_list *tlist );
>=20
> /* Moving through the list */
>=20
> /*
>  * Gets a hold of the first iterator in the list
>  *
>  * tlist
>  *    The list to get the beggining of
>  */
> struct tgdb_list_iterator *tgdb_list_get_first ( struct tgdb_list *tlist =
);
>=20
> /*
>  * Gets a hold of the last iterator in the list
>  *
>  * tlist
>  *    The list to get the last iterator.
>  */
> struct tgdb_list_iterator *tgdb_list_get_last ( struct tgdb_list *tlist );
>=20
> /*=20
>  * Moves the iterator one step forward through the list
>  *
>  * tlisti
>  *    The iterator to advance.
>  */
> struct tgdb_list_iterator *tgdb_list_next ( struct tgdb_list_iterator *tl=
isti );
>=20
> /*=20
>  * Moves the iterator one step backwards through the list
>  *
>  * tlisti
>  *    The iterator to move backwards.
>  */
> struct tgdb_list_iterator *tgdb_list_previous ( struct tgdb_list_iterator=
 *tlisti );
>=20
> /*
>  * Gets the data at the iterator's position.
>  *
>  * tlisti
>  *    The iterator to get the item at.
>  *
>  * return
>  *    The item at the iterator
>  */
> void *tgdb_get_item ( struct tgdb_list_iterator *tlisti );
>=20
> #endif /* __TGDB_LIST_H__ */

[Cgdb-devel] TGDB tgdb_list interface

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

Hi,

Could anyone critique the interface for tgdb_list that I am proposing?
This is what I came up with.

Basically, it will be a double linked list. You can get back an iterator
into the list. You can insert before or after the iterator. The front
end writers will only use it to traverse the list. The iterators have
next,previous functionality.

What does everyone think?


#ifndef __TGDB_LIST_H__
#define __TGDB_LIST_H__

#if HAVE_CONFIG_H
#include "config.h"
#endif /* HAVE_CONFIG_H */

struct tgdb_list;
struct tgdb_list_iterator;

typedef void (*item_func)(void *item);

/*=20
 * Initializes a new empty list.
 *=20
 * Returns
 *    The new list.
 */
struct tgdb_list *tgdb_list_init ( void );

/*=20
 * Appends item to the end of the list.
 *=20
 * tlist
 *    The list to append an item to.
 *
 * item
 *    The item to add to the list
 */
void tgdb_list_append ( struct tgdb_list *tlist, void *item );

/*=20
 * Prepends item to the beggining of the list.
 *=20
 * tlist
 *    The list to prepend an item to.
 *
 * item
 *    The item to add to the list
 */
void tgdb_list_prepend ( struct tgdb_list *tlist, void *item );

/*=20
 * appends the item after the position of the iterator.
 *=20
 * tlisti
 *    The iterator to insert after.
 *
 * item
 *    The item to add to the list
 */
void tgdb_list_insert_after ( struct tgdb_list_iterator *tlisti, void *item=
 );

/*=20
 * prepands the item before the position of the iterator.
 *=20
 * tlisti
 *    The iterator to insert before.
 *
 * item
 *    The item to add to the list
 */
void tgdb_list_insert_before ( struct tgdb_list_iterator *tlisti, void *ite=
m );

/* Traversing the tree */

/*=20
 * Traverses each item in the list, passing each element to func
 *
 * tlist
 *    The list to traverse
 *
 * func
 *    The function to call on each item
 */
void tgdb_list_foreach ( struct tgdb_list *tlist, item_func func );

/* Freeing the tree */

/*=20
 * Free's list item by calling func on each element
 * This function is different because it will free the list as it=20
 * traverses the list.
 *
 * tlist
 *    The list to free
 *
 * func
 *    The function to free an item
 */
void tgdb_list_free ( struct tgdb_list *tlist, item_func func );

/*=20
 * Gets the size of the list.
 *
 * tlist
 *    The list context to get the size of.
 *
 * Returns
 * 	  The size of the list, 0 if empty.
 */
int tgdb_list_size ( struct tgdb_list *tlist );

/* Moving through the list */

/*
 * Gets a hold of the first iterator in the list
 *
 * tlist
 *    The list to get the beggining of
 */
struct tgdb_list_iterator *tgdb_list_get_first ( struct tgdb_list *tlist );

/*
 * Gets a hold of the last iterator in the list
 *
 * tlist
 *    The list to get the last iterator.
 */
struct tgdb_list_iterator *tgdb_list_get_last ( struct tgdb_list *tlist );

/*=20
 * Moves the iterator one step forward through the list
 *
 * tlisti
 *    The iterator to advance.
 */
struct tgdb_list_iterator *tgdb_list_next ( struct tgdb_list_iterator *tlis=
ti );

/*=20
 * Moves the iterator one step backwards through the list
 *
 * tlisti
 *    The iterator to move backwards.
 */
struct tgdb_list_iterator *tgdb_list_previous ( struct tgdb_list_iterator *=
tlisti );

/*
 * Gets the data at the iterator's position.
 *
 * tlisti
 *    The iterator to get the item at.
 *
 * return
 *    The item at the iterator
 */
void *tgdb_get_item ( struct tgdb_list_iterator *tlisti );

#endif /* __TGDB_LIST_H__ */

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

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

On Wed, Sep 17, 2003 at 03:15:15PM -0400, Alain Magloire wrote:
> >=20
> >=20
> > --Qxx1br4bt0+wmkIi
> > Content-Type: text/plain; charset=3Dus-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >=20
> > Hi,
> >=20
> > =3D46rom 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.
> >=20
>=20
> 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.

Good point!

I will work on this.

Bob Rossi

Re: [Cgdb-devel] TGDB structures

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

On Wed, Sep 17, 2003 at 03:25:26PM -0400, Alain Magloire wrote:
> ..
>=20
> > > it is not very complicated either: a non-blocking way of verifying wh=
ether
> > > your pointer is still OK before writing to it is available on all ix8=
6=3D20
> > > 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 (almo=
st) =3D
> > just
> > > as fast.
> >=20
> > 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 )
> >=20
> > Any other considerations?
> >=20
> > 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.
> >=20
>=20
> 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.
>=20
> 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.
>=20
> 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 underst=
ood.
>=20
> my 0.0002 canadian.

Good point. I think we will worry about threads in 2.0 like you
suggested. However, we will try to write it in a way that is easy to
change to be "Thread-safe" and "Reentrant".

Since there is no front end that relies on this and there is a ton of
other work to do. Like the actual MI integration. :)

Bob Rossi

Re: [Cgdb-devel] TGDB architecture

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

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

Re: [Cgdb-devel] TGDB architecture

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

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