libGDB architecture
Stan Shebs
shebsATcygnus.com
Thu Sep 16 16:43:00 GMT 1999
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
More information about the Gdb
mailing list