Re: libGDB architecture

Re: libGDB architecture

[Greg Watson]

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

:-) :-)

Re: libGDB architecture

[Andrew Cagney]

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
From sja@brightstareng.com Tue Aug 24 20:47:00 1999
From: Stuart Adams <sja@brightstareng.com>
To: gdb@sourceware.cygnus.com
Subject: remote thread packet formats
Date: Tue, 24 Aug 1999 20:47:00 -0000
Message-id: <37C36799.69D64353@brightstareng.com>
X-SW-Source: 1999-q3/msg00231.html
Content-length: 439

Can anyone shed more light on the remote thread packet formats ???
I want to add thread support for a custom RTOS.

For example what does GDB expect in response to the "qL" and "qP"
commands ??? 

-- Stuart

------------------------------------------ 

Stuart Adams
Bright Star Engineering Inc.
19 Enfield Drive
Andover MA 01810 USA
Tel: +1-978-470-8738
Fax: +1-978-470-8878
Email: sja@brightstareng.com
Web: http://www.brightstareng.com/
From MPetzold@ELSA.de Wed Aug 25 07:02:00 1999
From: "Michael Petzold" <MPetzold@ELSA.de>
To: gdb@sourceware.cygnus.com
Subject: sh-stub.c question
Date: Wed, 25 Aug 1999 07:02:00 -0000
Message-id: <412567D8.0050A54E.00@elsa.de>
X-SW-Source: 1999-q3/msg00232.html
Content-length: 1307

Hi,

I'm trying to get gdb remote debugging to work with a SH-2 target. The gdb
distribution contains already a sample remote stub, sh-stub.c, which I'm
currently adapting to my needs.

A problem I encountered is that the exception vector table (via exceptions())
isn't generated as is intended. The code doesn't even compile... Gcc
(egcs-2.91.57 cross NT -> sh) says for the occurences of
code_for_catch_exeception(x): "inconsistent operand constraints". By this it
means the three lines which deal with the int parameter 'n'. Is token merging
supposed to work also with assembler templates? But I think it's rather the "i"
constraint, that announces 'n' as a constant, which is irritating gcc.

I found no way to get this nice _inlining_ idea work - at last I sort of
manually unrolled the calls to code_for_catch_exeception ;-(
Are there some special compiler switches (apart from -O3) that I should employ?
Or something else?

Thanks + regards,
Michael.


____________________________________________________________

 Michael Petzold        Engineering Consumer Communcations
 ELSA AG
 Sonnenweg 11           Phone:   +49-(0)241-606-0
 52070 Aachen           Fax:     +49-(0)241-606-2099
 Germany                E-Mail:  MPetzold@elsa.de
____________________________________________________________

Re: libGDB architecture

[Jim Blandy]

> > 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 <shebs AT cygnus.com>
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 <ovidiu@cup.hp.com>

   On Thu, 16 Sep 1999 21:20:48 +1000, Andrew Cagney <ac131313@cygnus.com> 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 <ac131313 AT cygnus.com>
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 <shebs AT cygnus.com>
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 <ac131313@cygnus.com>
   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

Re: libGDB architecture

[Ovidiu Predescu]

On 16 Sep 1999 14:08:39 -0500, Jim Blandy <jimb@cygnus.com> 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.
> > 
> > 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.

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.

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.

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

Greetings,
Ovidiu

--
Ovidiu Predescu <ovidiu@cup.hp.com>
http://andromeda.cup.hp.com/  (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/

Re: libGDB architecture

[James Ingham]

Andrew Cagney <ac131313@cygnus.com> writes:


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

I agree with Andrew here.  We can get a lot of benefit just breaking
down some of the atomic operations in the GDB interface into useable
bits.  We have already done this with the variable interface (see
gdbtk-variable.c)   Another example where you need to do this is in
the backtrace command.  For most GUI purposes, you really don't want
an undifferentiated list of 100 stack elements with all their
arguments, names, types...  Parsing and displaying this was very
slow.  You really want one command that just gives you the list of
functions on the stack.  Then a way to get the args (preferrably
already list-ified) for each level.  That way you can do intelligent
things like only fetch what fits in the current window, and get the
others on scrolling or whatever...

This is just one other example.  There are other places where
providing a more discrete interface into gdb would be a big benefit,
and probably reduce most of the need to get your hands on the actual
data in gdb.

I am still worried about parsing very large arrays, etc, however.  For 
this to be fast, you probably will have to somehow get the data
directly... 
 
> Your too trusting :-)
> 
> 	Andrew
> 
> PS: See Tcl_IncrRefCount and Tcl_DecrRefCount

There are actually two places where Tcl does preservation of data.
One is in the Object system, which uses the calls Andrew sites above,
and one is for clients that want to hold data over a call that may
potentially free it - see Tcl_Preserve and Tcl_EventuallyFree.

Jim
-- 
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham                                              jingham@cygnus.com
Cygnus Solutions Inc.
From msnyder@cygnus.com Sat Nov 27 18:50:00 1999
From: "Michael Snyder" <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: QUIT as a function?
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <7svn12$576$1@cronkite.cygnus.com>
References: <199909171842.LAA10740@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00336.html
Content-length: 594


Stan Shebs wrote in message <199909171842.LAA10740@andros.cygnus.com>...
>
>   From: Andrew Cagney <ac131313@cygnus.com>
>   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.

True, but there's so much going on in those symbol readers
(including file accesses) that I can't believe one function call,
even in the innermost loop, would make a measurable difference.