libGDB architecture

[Andrew Cagney]

Ovidiu Predescu wrote:
> 
> On 16 Sep 1999 14:08:39 -0500, Jim Blandy <jimb@cygnus.com> wrote:
> 

> > 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.

To re-iterate my position, as a first pass, I strongly prefer to keep a
certain distance between GDB's internals and the client.  When it comes
to performance, I can't see the access mechanisms provided for
primitives such as breakpoints and frames even appearing on the radar. 
In fact, to the best of my knowledge the current biggest hot spot
(everyone keeps pointing a finger at) is the overhead/hazards of
serializing GDB's communication (via a pty say).

I think a better (safer, more likely to succeed) approach would be to,
in parallel with the introduction of a robust interface, start
investigating what have been identified as other (likely) hot spots. 
Interestingly, many of the below are actually independent of the libGDB
interface:


	o	variable update when stepping

		I believe that the GDBtk team
		(who do access GDB's internals
		using a more direct mechanism)
		have already identified this as
		a performance hot spot.


	o	A per thread cache.
		Well actually the lack of it :-)

		Here is another example of why it is
		better to have the client keep a safe
		distance from GDB.  The last thing
		we want is for clients to be locked
		into the existing mechanisms.


	o	memory transfer / large target
		data structures

		In this case I think more 
		fundamental internal GDB changes
		will be needed before you can start
		thinking about providing direct access
		to GDB's internal memory structures.

		Perhaps HP are interested in taking on
		the task of re-working GDB's local memory
		cache so that a more direct interface is
		possible. I kind of suspect that papers
		on distributed shared memory would be
		highly relevant.

		While that work is in progress a slow
		robust mechanism would continue to be used.


	o	(as always)
		symbol table / name lookup

		A hot topic in anyone's language :-)


> 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.

(Stack frames are implemented using obstacks.)

I don't think it is reasonable to assume that the client is in control
:-). As GDB becomes more and more asynchronous it is just as likely that
the target will trigger events as it is the client.

Consider GDB debugging a multi-threaded target.  The long term plan is
for GDB to allow some threads to run free while others are halted - in
such a situation any assumption that the client is in control has to be
thrown out the window :-).

> 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 ;-).

Your too trusting :-)

	Andrew

PS: See Tcl_IncrRefCount and Tcl_DecrRefCount