[m-dev.] for review: a big step towards the trace-based debugger (part 3 of 3)

[Zoltan Somogyi]

> On 20-Mar-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > +** MR_trace_event_number is a simple counter of events. This is used in
> > +** two places: here, for display to the user and for skipping a given #
> > +** of events, and when printing an abort message, so that the programmer
> > +** can zero in on the source of the problem more quickly.
> >  */
> 
> I think this is a very cool idea.

Necessity is the mother of invention. Binary search for this number
was far too tedious.

> The comment at the top of the file about the trace_type
> (internal/external) should probably mention the existance of the #define
> for MR_USE_EXTERNAL_DEBUGGER being needed if external debugging is
> to actually work. 

After I commit this change, I intend to divide mercury_trace.c into smaller
pieces. I will do this then.

> > +	** If any code invoked by MR_trace is itself traced,
> > +	** MR_saved_regs will be overwritten, leading to a crash later on.
> > +	** This is one reason (but not the only one) why we turn off
> > +	** tracing when we call back Mercury code from this file.
> > +	*/
> 
> What are the other reasons?  They aren't specified up with the
> documentation near MR_trace_enabled (or whatever it's called).

I would have thought it was obvious. When you print the values of the
variables at a point in your program, you don't want to see

mtrace> 456 123 io__print	CALL	DET

at nauseam interspersed with the values you want to look at. (Tyson: d'oh!)

> I don't particularly care for the name "mmd".  How about "mdebug",
> "mercury-debug"?  I know we want to leave namespace for an Opium-style
> debugger, but I don't think the way to do it is with "mmd".  I'm
> happy for you to commit mmd for the moment, but I'd like to find a
> better name for a release.

mmd stands for Melbourne Mercury Debugger. The opium-style one could be
rmd, the Rennes Mercury Debugger :-)

The other name I thought of was mdb, in analogy to gdb.

Better get your votes in fast.

> > New File: tests/debugger/Mmakefile
> > MMD_WRAPPER = yes
> > 
> 
> What does this do?  It doesn't appear to be mentioned below.

Nothing. I was originally thinking of having it modify the rule for
deriving .out files (by putting mmd before the command line), but
interpreter.m needs a non-standard .out rule anyway (it needs a
command line argument. I have therefore deleted that line.

> Apart from my comments, this is good stuff!  Looking forward to never
> seeing Sicstus again (except as a column in some benchmarks, of course).

My current change is not yet enough to get rid of SICStus, but it helps.

> Diffs relative to this diff for next round, but I don't expect too many
> problems.

Due to the delay in these reviews, I have changed several other things,
so you will get a full diff this time as well. It still doesn't bootcheck
with --generate-trace (although it does without), but I won't have time
to track the problem down this week.

> Please make sure this change doesn't break stack traces before commiting.

Do you have a test case for this?

Zoltan.