mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-16 01:43:35 +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.
Threadscope
===========
This file contains information about threadscope profiling for Mercury.
1. Contact Info
2. Supported Systems.
3. Threadscope Profiling Tools
Contact Info
------------
Paul Bone
pbone@csse.unimelb.edu.au
Mercury Project
mercury@csse.unimelb.edu.au
http://www.mercury.csse.unimelb.edu.au
Supported Systems
-----------------
Threadscope uses the RDTSCP or RDTSC instructions found on some x86 and x86_64
processors to get fast, high precision timing information. These instructions
read the time stamp counter (TSC), this is incremented for every clock cycle.
Processors must increment this at a constant rate, regardless of their power
state, (see /proc/cpuinfo for constant_tsc).
TSC must also be synchronised between processors in the same system, although
it may be possible to work around this, let me know if you have such a system
(See contact info).
AMD processors do not seem to store their clock frequency in their brand ID
string. On these systems Theadscope profiles are not to scale since clock
counts cannot be converted into time in nanoseconds. The threadscope profile
will count one nanosecond for each clock tick.
I have had success with the following processors:
Intel Core2
Intel Xeon CPU X5472 (in a dual socket system).
Processors that do not work correctly:
AMD Athlon 64 X2
Threadscope Profiling Tools
---------------------------
Mercury supports threadscope profiling. See the profiling section in the user
guide.
The Threadscope profiling tools are written in Haskell and are known to work
with GHC 6.10. threadscope depends upon the following Haskell libraries:
array
binary
containers
filepath
ghc-events
gtk2hs
mtl
Many of these will be provided with GHC or packaged for/by your operating
system.
ghc-events is not packaged by most operating systems at this stage, It can be
retrieved from hackage:
http://hackage.haskell.org/package/ghc-events
threadscope itself can also be retrieved from hackage:
http://hackage.haskell.org/package/threadscope
Information about how to install Haskell packages can be found here:
http://haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package