[m-dev.] for review: nicer stack dumps
trd at stimpy.cs.mu.oz.au
Wed Apr 22 10:14:51 AEST 1998
On 21-Apr-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > + fprintf(stderr, "\t%s:%s/%ld (mode %ld, %s)\n",
> > + entry_layout->MR_sle_def_module,
> > + entry_layout->MR_sle_name,
> > + (long) entry_layout->MR_sle_arity,
> > + (long) entry_layout->MR_sle_mode,
> > + detism_names[entry_layout->MR_sle_detism]);
> This is fine as long as we are not too worried about what we print for
> automatically generated procedures. (The same goes for similar code
> in the tracer.)
Well, I'm not. Strictly speaking, we should run this string through the
demangler too, but I'm not too worried about that yet either.
> The rest of the diff looks OK.
> There are two further changes related to this, but they can be in
> separate checkins. One is to fill in the label name field of the
> label table with a NULL unless profiling is defined. This will cut
> down executable sizes significantly. The other is to give to this
Yep, will do that soon.
> stack dump utility the capability of the one in mercury_memory.c,
> i.e. compression of the stack dump via run-length encoding.
> I want to add a command to the debugger that will print the stack dump,
> but don't want to annoy people by printing
> list:member/2 (mode 1, semidet)
> 2000 times instead of printing
> 2000 * list:member/2 (mode 1, semidet)
> just once. (This is a real situation.) Actually, it would be even better
> if we recognized cycles of length > 1, up to a configurable limit, since
> sometimes a deep recursion involves two or more procedures (I recall that
> the parser has such code).
It's officially on the wish list.
Tyson Dowd # So I asked Sarah: what's the serial number on
# your computer? She replied:
trd at cs.mu.oz.au # A-C-2-4-0-V-/-5-0-H-Z
More information about the developers