Re: libGDB architecture

[Andrew Cagney <ac131313@cygnus.com>]

Greg Watson wrote:

> >Query/builder
> >-------------
> >
> >    This is the most fundamental of the proposed changes to GDB.  Up
> >until now, code that implementing a query operation returned raw text
> >(possibly annotated).  As explained in the previous section this
> >operation is both un-reliable and inefficient. [I'd better add an
> >explanation].
> 
> An alternative would be to expose the GDB object to the client. Is there
> any reason why this option was not chosen? Persumably the builder interface
> is going to need to know about all GDB objects anyway, and I'm going to
> need to supply routines to convert the result to my own local object.
> Actually, I'd rather have an abstract object that represents a GDB object
> handed to me by the query/event routines. Then I can just stick it on the
> (say) breakpoint list that I'm maintaining.

The problem with trying to expose the ``real GDB object'' to the client
is that, in many cases, the object in question doesn't actually exist.
What often appears to be part of an object is actually the result of
executing code.  Most of the details of a stack frame, for instance, are
obtained this way.

Regarding, breakpoints.  The CLI allows you to manipulate breakpoints
using GDB's internal breakpoint-number.  This interface doesn't expect
to be any different.   For breakpoints, the key changes are:

	o	the mechanism handing the client
		the identifer of a created breakpoint
		is tight.

	o	the mechanism used to obtain details
		of a breakpoint is robust.

The thing I guess that needs to be emphasized is that we're not trying
to rewrite GDB into an OO wonder. Rather we're trying to adapt GDB's
well understood and working interfaces so that they can be used as part
of a larger OO framework.  If we try to bite off more than that we're
probably doomed to go the same way as previous efforts :-)

> >Event notify
> >------------
> >
> >    The next component is the notify mechanism.  When GDB determines
> >that a significant event has occurred (memory changed, breakpoint
> >changed, target started, target stopped) it advises the target using a
> >notify call.
> >
> >    For each "object" that GDB can represent symbolically, there is
> >notify mechanism that allows GDB to inform the UI that information has
> >been invalidated.  The exact mechanism used depends on the type of data
> >involved.
> 
> What about events like process termination or if the target receives a
> signal and there is no associated object? Or is the whole target process
> going to be an object?

This was poorly explained.  There are two type of notify:

	o	object based (breakpoint, variable, ...)

	o	event based

		Target started, target stopped
		(it isn't that simple as a target can run as a
		result of things like expression evaluation)

> In the model I use, event notification is associated with the operation not
> the object. The limitation of this that I discovered recently is that some
> operations result in multiple responses, which ideally should be handled by
> multiple callbacks. I guess the limitation with your proposal is that every
> object that might change has to carry around an event routine handle.

When the target stops, there is the notion of a stop-reason.  That would
either be passed across at the time of the stop notify or available as a
query.

Why two choices, why hedge those bets?  Well, if you look at the WFI (er
wait-for-inferior) code, GDB constructs the stop reason on the fly as a
text sequence.  There currently is no ``why did we stop?'' function that
can be grabbed.

> >Operators (anyone got a better name)
> 
> Actions?

Maybe.

> >------------------------------------
> >
> >    An operator manipulates the state of GDB or the target.
> >
> >    An operation is either synchronous or asynchronous.  A synchronous
> >operation completes synchronously with the client.  An asynchronous
> >operation, which involves execution (free running) by the target, has no
> >bounded completion time.
> 
> Why distinguish synchronous and asynchronous operations? Why not make all
> operations async and let the client wait for completion if necessary
> (libGDB could provide a default "wait for last operation to complete"
> routine, or wrappers around the "sync" routines). Otherwise you mandate how
> certain operations interact with the client. e.g. suppose adding a
> breakpoint is slow to complete, then a GUI client will hang until the
> operation finishes. Also makes for a more complex interface.

It is a direct reflection of GDB's internal behavour:

	o	when the target has halted:
		GDB can reasonably expect operations to
		complete in a bounded period of time.

	o	when the target is running:
		GDB is unable to make any guarentees
		about the target's behavour

In the first case, there is a chance that the target could die part way
through an exchange.  That in turn could cause GDB to hang until a timer
kicks in.  It was felt that the probability of this was low and the
amount of effort needed to handle this case providing marginal return.

As a second pass (or as contributed code) this can be re-worked into a
simpler interface.

> >Output streams
> >--------------
> >
> >    In addition to providing access to the target (via the query/notify
> >mechanism), GDB also has a number of out-of-band text streams:
> >
> >    * output from the target (sim or remote)
> >
> >    * internal traces and logs
> >
> >    * CLI console output
> >
> >    Each of these text streams are implemented with corresponding stream
> >object.  A client can control a given stream by providing its own stream
> >implementation.
> 
> The output from the target needs to be separated into stdout and stderr.
> Also a target input stream also needs to be provided. It would be neat, and
> probably necessary for a GUI, if event notification could be used on stream
> objects.

Yes, eventually.  The target-output is driven by the need to support
embedded targets.  Native targets currently by-pass GDB when displaying
output.  I recall Jim Ingham explaining that a UNIX gui debugger should
create a separate window with PTY and start the program under that.

much thanks and keep the questions/comments comming,

	Andrew