[m-dev.] spypoints in external debugger

[Erwan Jahier]

| 
| 
| Hi,
| 
| I have two questions in regards to adding spypoints to the external
| debugger interface that are mainly directed to Fergus and Erwan.
| 
| The first is about return types.  I have implemented some changes to the
| interface that allow breakpoints to be added by using the procedures from
| mercury_trace_spy.h in much the same manner as the internal debugger
| does.  The debugger interface needs to reply to an 'add_breakpoint' 
| request with either an 'ok.' if the request was successful, or some other
| reply if the request could not be matched with an existing procedure or
| the request was ambiguous.  My question concerns how this should be done.
| Returning an 'ok.' term is obvious to me, but I'm unsure whether the other
| cases should return a term of their own, eg 'no_such_procedure.', or
| return an error term.  In my opinion, returning an error should not be
| used for returning information.  However, the internal debugger prints
| messages for these to stderr.  I simply needs some clarification about
| which approach I should be using.

Returning a different terms for each case seems better to me (especially if you
want to do some automatic processing that depends on the kind of error you get
into).

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

Euh... It's difficult to say without seeing your code. In principle, if you
mimics exactly what is done in mercury_trace_internal.c, it should work. 

To understand how spypoints are implemented, I have the feeling that the
revelant file for you to look at is mercury_trace.c and in particular the
function MR_trace_real(). Maybe for example you could check if the execution
really enters that function? And if it doesn't, try to understand why (it is
just a possible hint; but I am not sure what is the point you missed so...).

Hope that helps.

-- 
R1.


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