[m-dev.] for review: the new debugger command set

[Erwan Jahier]

Zoltan Somogyi wrote:
> 
> Since we want full debugger functionality in the release, this diff
> is for inclusion in the release. The nominated reviewers are Fergus
> and Tyson, but I would also like feedback from Erwan.

Sure.
Here some feedback. I may have another look tomorrow.

> 
> compiler/trace.m:
>         Remove from the call to MR_trace the parameters that are now in fixed
>         stack slots, since MR_trace can now look them up itself.
> 
>         After every call to MR_trace(), emit code that checks whether it
>         should jump away, and if yes, performs the jump. This is used to
>         implement retry. (The debugger cannot execute the jump itself
>         because it is in the wrong C stack frame.)
> 
>         When generating the set of live variables at internal ports,
>         the variables that are in the pre-death set of the goal into which
>         we are entering may not be available. However, the variables in the
>         pre-death set that are also in the resume vars set will be available,
>         so now include info about them in the layout structure for the event.
>         Since with tracing the non-clobbered input args are in all resume vars
>         sets, this ensures that these input args will be available from all
>         internal events.

If the cost of keeping those variables live is not infinitesimal, maybe
it
would be nice to make that information optional (since it can be
reconstructed
within my debugger and switch on and off dynamicly).


> runtime/mercury_trace.[ch]:
>         If MR_TRACE_HISTOGRAM is defined, record a count of the number of
>         events at each depth. This information can help us evaluate space-time
>         tradeoffs.
> 

Sorry it is totaly out of purpose but I can't help with showing you how
simply
(and funny ;-) this can be done in Opium...

%:- pred histogram(list(int)).
%:- mode histogram(out) is det.
histogram(List) :-
	histogram2(0, [], List).

%:- pred histogram2(int, list(int), list(int)).
%:- mode histogram2(in, in, out) is det.
histogram2(Depth, Lin, Lout) :-
	( step_np ->		% _np stands for no print
		current_depth(Depth1),
		( 
			Depth >= Depth1 
		->
			increment_nth_element_of_a_list(Depth1, Lin, L)
		;
			% D < D1    
			length(Lin, Length),
			( (Length < Depth1)  ->
				L = [1 | Lin]
			;
				increment_nth_element_of_a_list(Depth1, Lin, L)
			)
		),
		histogram2(Depth1, L, Lout)
	;
		% last event is reached, step_np failed.
		Lout = Lin
	).

%:- pred increment_nth_element_of_a_list(int, list(int), list(int)).
%:- mode increment_nth_element_of_a_list(in, in, out) is det.
increment_nth_element_of_a_list(N, Lin, Lout) :-
	[10 lines cut]


[rmdb]: run(hanoi(3)).	% hanoi N solves the hanoi towers problem for N
disks
[rmdb]: histogram(List), display_histogram(List).
last event is reached
 
List = [12, 6, 5, 3]

depth 1: 3 events
depth 2: 5 events
depth 3: 6 events
depth 4: 12 events
[rmdb]: 


> Index: doc/user_guide.texi
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/doc/user_guide.texi,v
> retrieving revision 1.134
> diff -u -u -r1.134 user_guide.texi
> --- user_guide.texi     1998/09/10 06:55:21     1.134
> +++ user_guide.texi     1998/09/10 09:57:28

[...]

> +Mercury also supports these four kinds of events,
> +but not all events can occur for every procedure call.
> +Which events can occur for a procedure call, and in what order,
> +depend on the determinism of the procedure.
> +The possible event sequences for procedures of the various determinisms
> +are as follows.
> +
> + at table @var
> + at item nondet procedures
> +a call event, zero or more repeats of (exit event, redo event), and a fail event
> + at item multi procedures
> +a call event, one or more repeats of (exit event, redo event), and a fail event

For multi procedures I would say:
a call event, zero or more repeats of (exit event, redo event), and a
exit event

[...]

> + at node Preparing a program for debugging
> + at section Preparing a program for debugging
> +
> +Mercury debugging works by embedding calls to the debugging system
> +into the executable code of Mercury procedures,
> +at the execution points that represent trace events.

I suggest:

Trace extraction is performed by embedding calls to the debugging system
into the executable code of Mercury procedures; each such call generate
a
trace event.

[...]

> + at item finish [-NSans] [@var{num}]
> +Continues execution until it reaches a final (EXIT or FAIL) port of
> +the @var{num}'th ancestor of the call to which the current event refers.
> +The default value of @var{num} is zero,
> +which means skipping to the end of the current call.
> +Reports an error if execution is already at the desired port.
> + at sp 1
> +The options @samp{-n} or @samp{--none}, @samp{-s} or @samp{--some},
> + at samp{-a} or @samp{--all} specify the print level to use
> +for the duration of the command,
> +while the options @samp{-S} or @samp{--strict}
> +and @samp{-N} or @samp{--nostrict} specify
> +the strictness of the command.
> + at sp 1
> +By default, this command is strict, and it uses the default print level.
> + at sp 1
> + at item forward [-NSans]
> +Continues the program until the program resumes forward execution,

I feel like a word is missing:
"Continues the program execution until [...]" ?

> +i.e. until it reaches a non-final port inside any predicate. Reports

don't you mean a final port here ?

> +an error if the current event refers to a non-final port.

don't you mean a final port again ???

[...]

> + at sp 1
> +The debugger can perform a retry only from an exit or fail port;
> +only at these ports does the debugger have enough information
> +to figure out how to reset the stacks.
> +If the debugger is not at such a port when a retry command is given,
> +the debugger will continue forward execution
> +until it reaches an exit or fail port of the call to be retries
> +before it performs the retry.
> +This may require a noticeable amount of time.
> + at c XXX not yet
> + at c and may result in the execution of I/O and/or other side-effects.

oh ? I thougth Mercury was side-effect free ;-)
Shouldn't you forbid retry command when the current procedure performs
I/O ?
or at least warn the user that a retry command may not be safe in those
cases
(and possibly prompt for a confirmation ?).

[...]

> + at item stack
> +Prints the names of the ancestors of the call specified by the
> +current event. If two or more ancestor calls are for the same
> +predicate, the procedure identification will be printed once
> +with the appropriate multiplicity annotation.
> + at sp 1
> +This command will report an error if there is no stack trace
> +information available about any ancestor.

Did you chose to report an error in that case because it was difficult
to
implement or because you thougth that printing such a stack traces has
no sense
if one of the ancestors is missing ?

[...]

> + at sp 1
> + at node Experimental commands
> + at subsection Experimental commands
> + at sp 1
> + at table @code
*****
> + at item histogram_all @var{filename}
> +Prints (to file @var{filename})
> +a histogram that counts all events at various depths
> +since the start of the program.
> +This histogram is available
> +only in some experimental versions of the Mercury runtime system.
> + at sp 1
*****
> + at item histogram_exp @var{filename}
> +Prints (to file @var{filename})
> +a histogram that counts all events at various depths
> +since the start of the program or since the histogram was last cleared.
> +This histogram is available
> +only in some experimental versions of the Mercury runtime system.
> + at sp 1
*****
copy-paste-paste error here.


-- 
R1.