[m-dev.] for review: uplevel printing

Tyson Dowd trd at stimpy.cs.mu.oz.au
Thu Jun 18 15:25:06 AEST 1998


On 17-Jun-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> Tyson, please review this.
> 
> Estimated hours taken: 20
> 
> Allow the debugger to print the values of variables in ancestors
> of the current call. This requires knowledge about which named variables
> are live at call return sites. Providing this information properly required
> fixing the interaction of execution tracing and accurate garbage collection.
> 
> compiler/globals.m:
> 	Introduce a new trace level, so that there are now four:
> 	none, interface, interface_ports (corresponding to the existing
> 	three levels) and the new level interface_ports_returns,
> 	each of which requires all the information required by lower
> 	levels.
> 
> 	Make the trace level abstract, since in the future we may want to
> 	introduce trace levels for new combinations, e.g. interfaces and
> 	returns but not internal ports. Introduce the necessary new
> 	predicates.
> 
> compiler/continuation_info.m:
> 	Redefine internal_label_info to allow us to record separate info about
> 	the sets of vars needed at (a) internal ports of execution tracing
> 	and at (b) call return points for accurate gc or (now) uplevel
> 	printing during execution tracing. Neither is a subset of the other,
> 	and they need to be treated differently.
> 
> compiler/mercury_compile.m:
> 	Gather information about vars at return labels if the trace level
> 	requires uplevel printing capability, even if agc is off.
> 
> compiler/stack_layout.m:
> 	Fix the handling of labels which are needed both by agc and by
> 	execution tracing. If information at a return label is needed only
> 	by uplevel printing in execution tracing and not by agc, then
> 	discard all info about lvals which do not hold named variables
> 	or their typeinfos (in fact we keep all typeinfos at the moment).
> 	If a label is both the label of a port and a return label, we
> 	include in the layout structure the union of the information
> 	recorded for the two roles.
> 
> 	Sort the var_info vector before using it to generate layout
> 	structures in an attempt to make llds_common more effective
> 	and to make lists of variables printed by the debugger look better.
> 
> 	Record a distinguished value when there is no info about the vars
> 	live at a label, rather than (incorrectly) recording that there
> 	are no live variables. Before up-level printing, the lie was harmless;
> 	now it isn't.
> 
> 	Remove the label number from return label layouts, since the tracer
> 	isn't expecting it. It used to be included for debugging purposes 
> 	if the label was for agc, but it is possible for a label to be needed
> 	both for agc and for execution tracing. If Tyson finds he needs the
> 	label number, it can be easily turned back on for all label layouts.
> 
> compiler/code_info.m:
> 	Conform to the new definition of internal_label_info.
> 
> 	Rename an internal pred for clarity.
> 
> 	Rename some bool parameter to correctly reflect their new meaning.
> 
> compiler/*.m:
> 	Trivial changes, mostly due to making trace_level an abstract type.
> 
> runtime/mercury_stack_layout.h:
> 	Remove the label number from return label layouts, since the tracer
> 	isn't expecting it.
> 
> runtime/mercury_stack_trace.[ch]:
> 	Add a new function that returns the label layout structure at the
> 	Nth ancestor return continuation, together with the values of
> 	sp and curfr at that point. This required changing MR_stack_walk_step
> 	to step from an entry layout only to the return label layout.
> 
> runtime/mercury_stacks.h:
> 	Add macros that let us access detstackvars and framevars based on
> 	these synthesized values of sp and curfr.
> 
> runtime/mercury_trace_util.[ch]:
> 	Generalize several functions to allow them to use synthesized
> 	(as opposed to saved) values of sp and curfr in looking up values.
> 
> 	Retain functions with the original names and signatures that call
> 	the new, general versions with the necessary additional parameters.
> 
> runtime/mercury_trace_internal.c:
> 	Add a new command that sets the "ancestor level". For example,
> 	"l 2" sets it to 2, which means that the command "v" and "p" will
> 	refer to the grandparent of the current call. The ancestor level
> 	persists while the debugger is at the current event; after that
> 	it is reset to 0.
> 
> 	The implementation involves calling the new function in
> 	mercury_stack_trace.c and the generalized functions in
> 	mercury_trace_util.c.
> 
> 	Also add a deliberately undocumented extra command, X, which
> 	prints the stack pointers.
> 
> NEWS:
> 	Add a reminder about removing the X command before release.
> 
> The updates of the debugger test files will come after I bootcheck
> this.
> 
> Zoltan.
> 

> Index: compiler/continuation_info.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/continuation_info.m,v
> retrieving revision 1.12
> diff -u -u -r1.12 continuation_info.m
> --- continuation_info.m	1998/04/17 06:55:36	1.12
> +++ continuation_info.m	1998/06/17 06:10:34

> +	%
> +	% We may be interested in the layout of things at a label for three
> +	% different reasons: for stack tracing, for accurate gc, and for
> +	% execution tracing.
> +	%

4 reasons now.

> +	% - For stack tracing, we are interested only in call return labels.
> +	%   Even for these, we need only the pointer to the procedure layout
> +	%   info; we do not need any information about variables.
> +	%
> +	% - For accurate gc, we are interested only in call return labels.
> +	%   We need to know about all the variables that can be accessed
> +	%   after the label; this is the intersection of all the variables
> +	%   denoted as live in the call instructions. (Variables which
> +	%   are not in the intersection are not guaranteed to have a
> +	%   meaningful value on all execution paths that lead to the label.)
> +	%
> +	% - For execution tracing, our primary interest is in trace port
> +	%   labels. At these labels we only want info about named variables,
> +	%   but we may want this info even if the variable will never be
> +	%   referred to again.
> +	%
> +	%   For supporting up-level printing, we are also interested in

Should be like the other ones, i.e.

%  - For supporting up-level printing, we are also interested in


The rest looks ok (and quite useful), thanks.

-- 
       Tyson Dowd           # "Bill Gates is a white persian cat and a monocle
                            # away from becoming another James Bond villan."
     trd at cs.mu.oz.au        # "No Mr Bond, I expect you to upgrade."
http://www.cs.mu.oz.au/~trd #                -- Dennis Miller and Terri Branch



More information about the developers mailing list