This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: libGDB architecture
- To: gdb@sourceware.cygnus.com
- Subject: Re: libGDB architecture
- From: Greg Watson <g.watson@computer.org>
- Date: Tue, 24 Aug 1999 17:02:46 +1000
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();
:-) :-)