Re: libGDB architecture

[Greg Watson <g.watson@computer.org>]

Andrew,

I have a few comments from the "client end." Apologies if these have 
already been debated at length.

Cheers,

Greg



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

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

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.


>Operators (anyone got a better name)

Actions?

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

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

>Start Up
>--------
>
>    Since the objective is to facilitate the addition of new GUI and
>scripting interfaces integrated into GDB (rather than separate as with
>DDD) a more clearly defined startup mechanism is required.
>
>    That sequence is still being defined.

InitGDB();

while ( !Finished )
{
         ...
}

EndGDB();

:-) :-)