[m-dev.] proposed command set for the internal trace based debugger

[Fergus Henderson]

On 03-Jun-1998, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> 
> I don't really see an advantage of the logging scheme over the mostly
> destructive scheme.

The logging scheme can be easily automated, whereas with the mdi
scheme, the user needs to write mdi versions of every di-moded
`pragma c_code'.

In the general case, writing mdi versions is not possible,
because I/O can cause irreversable side effects.

> When doing file-based IO, undoing is usually not too hard.  For reading or
> sequential writing, the usual cases, you just need to store the file
> position.

That works OK for random access files, but what about pipes or sockets?

> For non-sequential writing, you'll have to save what is about to
> be written over so you can put it back (or you could always spit out an
> error message when the user tried to redo over something like this.  For
> file deletion, you could just rename the file instead, and remember to
> actually delete it later.  None of this seems terribly hard.

Well, maybe not, but none of it seems terribly easy either!
It seems much better if we can avoid burdening the user
with implementing this for every third-party foreign language library
they use that does I/O.

> As for screen IO, that can't really be undone,but I actually think that's
> an advantage.  When you're debugging some code that prints out the wrong
> thing, the easy way to do it is to skip over something, and see if the wrong
> thing comes out on your screen.  If so, you retry, creep a bit, and
> recursively try the same thing; if not, you creep and recursively try the
> same thing. If the IO only happens once, you can't see what's happening the
> second time.

This only works for simple stream-based text screen I/O.
For more general (e.g. curses-based) text screen I/O the screen display
will be entirely garbled.  Log-based I/O could 

> > > > You seem to have omitted the REDO port.  That one's pretty important.
> > > 
> > > We did not omit it by oversight. The Mercury execution model does not
> > > permit a redo port without requiring the compiler to perform a pessimization.
> 
> For the Quintus debugger, we handled this by having the debugger create the
> needed choicepoints.

Ah, I see: MR_trace() can check if this is an EXIT port for
a model_non procedure, and if so, and if the procedure left
some choice points on the nondet stack (i.e. curfr != maxfr || maxfr->redoip),
then it can push another frame on the nondet stack.

Yes, we could do this.  It would add some runtime overhead
for debugged code.  I think it would probably be about equally
easy to do it in the code generator (which would avoid the
need for a checking at runtime to see if each port was an
EXIT port for a model_non procedure).  It's a space/time trade-off.

> Of course, the Quintus debugger is a one-process
> debugger, so this was pretty easy.

So is the current Mercury debugger.

Even for the two-process debugger that Erwin is writing,
the debuggee process includes code in the Mercury runtime
for a function MR_trace() that is called at each debugging
event and that writes the relevant information to a socket.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.