mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-09 19:02:18 +00:00
c733b0359b
Estimated hours taken: 30
Branches: main
Give the Mercury debugger the ability to detect cliques of mutually recursive
predicates on the stack. Exploit this ability to enhance the debugger's
level, retry, finish and stack commands.
runtime/mercury_stack_trace.[ch]:
Add a function, MR_find_clique_entry, that detects the clique
that contains the top stack frame. This is used to implement the new
arguments "clentry" and "clparent" (short for clique entry and parent)
options of the level, retry and finish commands. "clique" is a synonym
for "clentry" in these commands.
Add a function, MR_dump_stack_layout_clique, that implements the
new capabilities of the stack command. It can detect more than one
clique, anywhere on the stack.
To make this possible, modify the existing functions for printing
the lines of stack traces. These used to keep some information around
between calls in global variables. Now that information is stored in
two structures that the caller passes them. One contains the parameters
that govern what is to be printed, the other contains information about
what has been buffered up to be printed, but has not been flushed yet.
(The old code was confused in its handling of parameters. Some parts
of it looked up the global variables storing them, while other parts
were given the parameter values by their callers, values that could
have been -but weren't- inconsistent.)
Change the buffer flushing code to be idempotent, since in the new
code, sometimes it is hard to avoid flushing the buffer more than once,
and we want only the first to print its contents.
Make some type names conform to our standard style.
runtime/mercury_stack_layout.h:
Add a new flag in MR_ProcLayouts: a flag that indicates that the
procedure has one or more higher order arguments. The new code in
mercury_stack_trace.c handles procedures with this flag specially:
it does not consider two non-consecutive occurrences of such procedures
on the stack to be necessarily part of the same clique. This is to
avoid having two calls to e.g. list.map in different part of the
program pulling all the procedures between those parts on the stack
into a single clique. (The deep profiler has a very similar tweak.)
Add a pointer to the corresponding part of the compiler.
compiler/hlds_pred.m:
Add a predicate to test whether a predicate has any higher order args.
compiler/stack_layout.m:
When computing the flag in proc layouts, call the new procedure in
hlds_pred.m to help figure it out.
trace/mercury_trace_cmd_backward.c:
Implement the new options of the "retry" command.
trace/mercury_trace_cmd_forward.c:
Implement the new options of the "finish" command.
trace/mercury_trace_cmd_browsing.c:
Implement the "new options of the "level" command.
Implement the new functionality of the "stack" command.
trace/mercury_trace_util.[ch]:
Add some code common to the implementations of the level, retry and
finish commands.
trace/mercury_trace_external.c:
Conform to the changes to the runtime.
doc/user_guide.texi:
Document the debugger's new capabilities.
NEWS:
Announce the debugger's new capabilities.
tests/debugger/mutrec.{m,inp,exp}:
A new test case to test the handling of the stack command
in the presence of cliques.
tests/debugger/mutrec_higher_order.{m,inp,exp}:
A new test case to test the handling of the stack command
in the presence of cliques and higher order predicates.
tests/debugger/Mmakefile:
Enable both new test cases.
This directory holds the trace subsystem, i.e. the part of the Mercury debugger that is written in C code. Notes on interfacing with other subsystems ------------------------------------------ If tracing is enabled, the compiler includes calls to MR_trace() in the generated C code. The trace subsystem in this directory is therefore called directly from Mercury code, via MR_trace() in runtime/mercury_trace_base.c. One of the first things it does is to save the original values of the Mercury registers in a variable called `saved_regs'. The reason it needs to do this is that the code here may modify registers, e.g. by allocating memory using incr_hp or by calling Mercury code. Once the original values of the registers have been saved, the trace subsystem is free to modify the Mercury registers. So for all code in this directory, the usual convention is that the original values of the Mercury registers are in `saved_regs', while the current (scratch) values for the normal non-transient Mercury registers etc. are in their normal locations, not in the fake_reg copies, and the transient (register window) registers, if any, are in the fake_reg copies. Any code which uses macros such as incr_hp(), list_cons(), make_aligned_string(), etc. that modify the heap pointer must call restore_transient_regs() beforehand and must call save_transient_regs() afterwards. The simplest way to do this is to use the macro MR_TRACE_USE_HP() in trace/mercury_trace_util.h. The tracer may invoke Mercury code defined in the browser or library directories if that code is exported to C using `pragma export'. But any calls from functions here to code defined in Mercury and exported using `pragma export', i.e. functions starting with `ML_' prefixes, must be preceded by a call to save_registers() and followed by a call to restore_registers(). The simplest way to do this is to use the macro MR_TRACE_CALL_MERCURY() in trace/mercury_trace_util.h.