[m-dev.] for review: nicer stack dumps

[Tyson Dowd]

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
http://www.cs.mu.oz.au/~trd #