This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: libGDB architecture
- To: Ovidiu Predescu <ovidiu AT cup.hp dot com>
- Subject: Re: libGDB architecture
- From: Jim Blandy <jimb AT cygnus dot com>
- Date: 16 Sep 1999 14:08:39 -0500
- Cc: Andrew Cagney <ac131313 AT cygnus dot com>, Stan Shebs <shebs AT cygnus dot com>, gdb AT sourceware.cygnus dot com
- References: <199909161655.JAA11061@hpcll563.cup.hp.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.