[m-dev.] spypoints in external debugger

[Gregory Daniel Denehy]

On Tue, 28 Sep 1999, Erwan Jahier wrote:

> | My question relates to how this should be
> | implemented.  I envisage that after the external debugger sends
> | 'spypoint_matched_print' it could be placed into a 'waiting' state, where
> | the external process could request the additional data as required, and
> | will resume execution only when it receives a continue request of some
> | kind.  I would be grateful for any comments/ideas on this.
> 
> Well, it is exactly the way it is currently working. Once you have done a
> "forward move", the debugger is in a waiting state: it is waiting for an other
> 'forward_move' request or a 'current_*' that will retrieve informations that can
> (for example) be printed.

This is true if the forward move request has been matched, however, if a
spypoint has been reached the execution will have been stopped before
reaching the requested event (and the request is forgotten).  What I'm
proposing is for the request to be remembered while waiting and to
continue searching for the same requested event after the external process
is finished retrieving its data.  It may very well be easier/better to
leave it the way it is, and make the external process (the graphical
debugger) remember what it was asking for, and then ask for it again if it
received a spypoint 'print' response.  Considering my current time
constraints I may have to leave it the way it is, and I'm content to do
so, but I wanted to know if there was a better way to do it.

Thanks for the input

Greg

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------