From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Ovidiu Predescu Cc: Andrew Cagney , Stan Shebs , gdb AT sourceware.cygnus.com Subject: Re: libGDB architecture Date: Thu, 16 Sep 1999 12:15:00 -0000 Message-id: References: <199909161655.JAA11061@hpcll563.cup.hp.com> X-SW-Source: 1999-q3/msg00362.html > > 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 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 On Thu, 16 Sep 1999 21:20:48 +1000, Andrew Cagney 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 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 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 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