[m-dev.] for review: a big step towards the trace-based debugger (part 3 of 3)
zs at cs.mu.OZ.AU
Wed Apr 1 12:20:23 AEST 1998
> 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
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?
More information about the developers