[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:
> On Wed, 3 Jun 1998, Fergus Henderson wrote:
> 
> [Re: the distinction between spy and break points]
> 
> > > The distinction might make a lot of sense internally, but from the user's
> > > point of view I think it would be simpler to think of them as the same
> > > thing.  
> > 
> > I think you have it backwards.
> > 
> > I think there are (at least) two important groups of users to take into
> > account:
> > 
> > 	(a) users that have used Prolog debuggers
> > 	(b) users that have used imperative language debuggers
> > 
> > For those in group (a), the concept of "spy points" that stop at any
> > port will already be familiar.  For those in group (b), the concept
> > of "break points" that just stop at a particular place in the program
> > will already be familiar.  So yes, spy point versus break point
> > is just one of quite a few orthogonal dimensions in which the
> > properties of a spy/break point can vary.  But because of the
> > historical background I think the distinction between the two
> > is important.  It's useful to give a name to the two different
> > concepts.
> 
> But I'm not so sure that break points correspond very closely to break
> points in imperative language debuggers.  In an imperative language, you
> usually put a breakpoint on a line of code, and usually on any line that has
> generated code associated, even just arithmetic calculations.  Instead, a
> Mercury break point is placed on a place in the code based on a structural
> description which will be difficult for a novice to understand.

The normal way of setting a break point with the Mercury
debugger will be either by saying "break <procedure>"
(meaning "set a break point at the specified procedure")
or just "break" (meaning "set a break point at the current location").
Both of these correspond very closely to the imperative language
notion of breakpoints.  The fact that we (currently) don't
provide a "break <line-number>" command doesn't mean that the
underlying concept is different.

> And
> imperative language debuggers allow you to put a break point on a procedure,
> but the Mercury debugger won't (it'll have to be a spy point).

That's not correct.  The Mercury debugger will let you put a break point
on a procedure.

> While on the subject, I have another comment.  It would be much more
> comfortable for users to be able to refer to a particular place in the code
> in a more lexical way.

Yes, I agree.

> For the Quintus debugger we used the calling
> predicate, the called predicate, the clause number, and the ordinal number
> of the call in that clause.  Another alternative would be line number in the
> source file.  Would it be very hard for you to support one of these?  The
> latter would seem to be pretty easy, since you keep the line number around,
> at least for a while, during compilation.  If you just emit some sort of
> table for each file, or something like that, I would think you could allow a
> more straightforward way of specifying a break point.

We discussed this a bit at our meeting on Friday.
The break point -> line number mapping (which would be useful for
a source-linked debugger) is quite doable, and ought to be done soon.

The line number -> break point mapping is a bit trickier, since
we currently don't provide any way to step through line at a time --
many lines containing code don't have an associated call to MR_trace().
If a line number has no associated break point, and the user requests
a break point at that line, then we could just pick the "closest" break point,
but that might lead to confusing results.

One way to solve this would be to get the compiler to insert more
freqent calls to MR_trace(), in particular inserting calls to
MR_trace() with a new "STEP" port whenever the line number of the goal
it is generating is different to the line number of the code which
caused the most recent call to MR_trace().  This would allow you to
step through the code in a more fine-grained way, like with gdb, and
(if, as you suggest, we keep a line number table to allow the reverse
mapping) this would allow you to set breakpoints on individual lines.
On the other hand, it would also increase the size of generated
executables (and hence the compilation time).

This is all work, though.  In the long term I would like us to aim for
supporting break points (and stepping through code) in a similar manner
to imperative language debuggers.  But in the short term we won't
support the "break <line-number>" command.

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