Re: libGDB architecture

[Jim Blandy <jimb AT cygnus.com>]

> > A consequence of handing out pointers to internal GDB data structures is
> > that GDB's internals and the external client need to reach a very clear
> > concensus over the life time of those objects.  I understand that tcl
> > has a mechanism that allows it and the low level code to keep a
> > reference count.
> 
> This is indeed a problem. However I think it could be solved pretty
> easily by putting a reference count variable in each structure that
> we export. Stop, stop, don't think that we need to change the memory
> handling policy inside GDB once we've added this instance variable.
> 
> We don't need to do that. This refcount is set to one for each GDB
> internal data structure that is exported by libGDB, at the time of
> its inception. When a client imports such a structure, it increments
> the refcount. We then modify the free() functions slightly, like
> this:

How should we handle objects allocated on obstacks?  Most of the
symbolic info (types; variables) is allocated this way.  I don't think
it's practical to keep the entire obstack around until all its
objects' reference counts have dropped to zero.
From shebsATcygnus.com Thu Sep 16 16:43:00 1999
From: Stan Shebs <shebs AT cygnus.com>
To: ovidiu AT cup.hp.com
Cc: gdb AT sourceware.cygnus.com
Subject: Re: libGDB architecture
Date: Thu, 16 Sep 1999 16:43:00 -0000
Message-id: <199909162343.QAA07102@andros.cygnus.com>
References: <199909161655.JAA11061@hpcll563.cup.hp.com>
X-SW-Source: 1999-q3/msg00363.html
Content-length: 1591

   Date: Thu, 16 Sep 1999 09:55:28 -0700
   From: Ovidiu Predescu <ovidiu@cup.hp.com>

   On Thu, 16 Sep 1999 21:20:48 +1000, Andrew Cagney <ac131313@cygnus.com> wrote:

   > A consequence of handing out pointers to internal GDB data structures is
   > that GDB's internals and the external client need to reach a very clear
   > concensus over the life time of those objects.  I understand that tcl
   > has a mechanism that allows it and the low level code to keep a
   > reference count.

   This is indeed a problem. However I think it could be solved pretty easily by
   putting a reference count variable in each structure that we export. Stop,
   stop, don't think that we need to change the memory handling policy inside GDB
   once we've added this instance variable.

As JimB observes, GDB can do mass releases of large numbers of objects
just by zapping an obstack, that being one of the handy features of
obstacks.  I don't think we'd want to scan through every object to see
if the obstack's removal also takes out the last ref to the object.

But these kinds of considerations are heavily dependent on the
particular object.  Reference counting for breakpoint objects would be
trivial, but rather more complicated for a member of a locally-scoped
struct.  In fact, there's nothing to stop us from using handles for
some kinds of objects, and reference counting on raw data for other
kinds.  That's why I'm so keen to see the list of desired objects and
operations.  Once we have the concrete requirements for libgdb, we're
in a better position to design the API.

								Stan
From ac131313ATcygnus.com Thu Sep 16 22:15:00 1999
From: Andrew Cagney <ac131313 AT cygnus.com>
To: gdb AT sourceware.cygnus.com
Subject: QUIT as a function?
Date: Thu, 16 Sep 1999 22:15:00 -0000
Message-id: <37E1CE42.4FEF9F66@cygnus.com>
X-SW-Source: 1999-q3/msg00364.html
Content-length: 139

Hello,

Is there any reason for not converting QUIT into a function?

	Andrew

Death to macro's.....
PS: Where is PROGRESS defined?
From shebsATcygnus.com Fri Sep 17 11:42:00 1999
From: Stan Shebs <shebs AT cygnus.com>
To: cagney AT cygnus.com
Cc: gdb AT sourceware.cygnus.com
Subject: Re: QUIT as a function?
Date: Fri, 17 Sep 1999 11:42:00 -0000
Message-id: <199909171842.LAA10740@andros.cygnus.com>
References: <37E1CE42.4FEF9F66@cygnus.com>
X-SW-Source: 1999-q3/msg00365.html
Content-length: 904

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Fri, 17 Sep 1999 15:14:42 +1000

   Is there any reason for not converting QUIT into a function?

Yes, QUIT appears in the inner loops of the symbol readers, which
are known to be compute-bound and some of the most time-critical
code in all GDB.  So I'd want to see some comparative performance
numbers, especially on hosts with lame calling conventions, before
we go messing with QUIT.

   PS: Where is PROGRESS defined?

include/mpw/spin.h.  Needed for Mac MPW, which requires explicit
yields to give other processes time.  Possibly of interest for DJGPP
also, and also for GUIs that want to do any sort of cursor animation
linked to computation.  For instance, MPW uses a spinning "beach ball"
- as long as it's spinning, things are OK and the computation is
making progress, but if it stops, you know something bad has happened...

								Stan