Re: libGDB architecture

[Ovidiu Predescu <ovidiu AT cup dot hp dot com>]

On 16 Sep 1999 14:08:39 -0500, Jim Blandy <jimb@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.
> > 
> > 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.

I think we should expect clients to behave nicely and not keep references to
such objects around for an indefinite time. Once they get a message that such
an object became invalid, the client should release its reference. Another
approach for the client would be to copy such information in its own internal
data structures, if they are needed for a longer time, but this shouldn't be
the case.

Releasing the obstacks happens usually as a result of an action triggered by
the client, so it should be prepared to release these objects. We can document
which are those functions in the API that deallocate entire obstacks; these
shouldn't be that many, the only important places I can think of are associated
with freeing of an object file and reloading of symbols.

Either way we need the client's cooperation, which is what you require anyway
from somebody that lives with you in the same data space ;-).

Greetings,
Ovidiu

--
Ovidiu Predescu <ovidiu@cup.hp.com>
http://andromeda.cup.hp.com/  (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/