[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