[m-dev.] spypoints in external debugger

[Gregory Daniel Denehy]

On Thu, 16 Sep 1999, Fergus Henderson wrote:

> On 15-Sep-1999, Gregory Daniel Denehy <gdenehy at cs.monash.edu.au> wrote:
> > 
> > 
> > My second question is concerned with how the spypoints themselves are to
> > implemented.  I'm able to add spypoints to the spypoint table, however,
> > I'm unable to get the execution to stop when it reaches a spypoint.  What
> > needs to be done here?
> 
> Basically you need to set the `must_check' flag properly.
> Currently there were two bugs where we were failing to
> set that properly: it was not being initialized properly,
> and the code in MR_trace_external_event() was not setting
> it properly either.
> 
> The following changes should fix it, I think.
> I will commit this.  I haven't tested them, though,
> so it would be great if you could let me know if they work.

That did the job (I think), however, it seemed to required one further
change.  From what I can make out, the external debugger (or the
underlying trace) steps through the events individually using a
MR_CMD_GOTO command and then matches the event against the event
specification from a forward_move request in MR_trace_event_external().
Because the event will always match the MR_CMD_GOTO event number in
MR_trace_real(), the check_stop_print is never checked and the spypoint is
never matched.  I've worked around this by checking for a spypoint match,
in addition to an event match, in MR_trace_event_external().

Now that I have the execution stopping for spypoints, I've another
question.  Ideally, I'd like the debugger to be able to print on reaching
a spypoint instead of stopping, as with the internal debugger.  What I had
in mind was to provide additional return values to 
forward_move_match_found, eg spypoint_matched and spypoint_matched_print.
'spypoint_matched' would be the same as forward_move_match_found, however,
I'm unsure of how to handle the 'spypoint_matched_print' case.  I require
details about the event that was matched so that it can be printed.
However, I'll also need further information including stack information
and variable values, etc.  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.

Thanks

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