From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ovidiu Predescu To: Jim Blandy Cc: Ovidiu Predescu , Andrew Cagney , Stan Shebs , gdb AT sourceware.cygnus.com Subject: Re: libGDB architecture Date: Fri, 17 Sep 1999 18:18:00 -0000 Message-id: <199909162200.PAA21351@hercules.cup.hp.com> References: X-SW-Source: 1999-q3/msg00366.html On 16 Sep 1999 14:08:39 -0500, Jim Blandy 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 http://andromeda.cup.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/