[m-rev.] for review: making user events more useful
Julien Fischer
juliensf at csse.unimelb.edu.au
Mon Dec 4 18:52:05 AEDT 2006
On Mon, 4 Dec 2006, Zoltan Somogyi wrote:
> Implement some of Mark's wish list for making user events more useful.
>
> 1. When executing "print *" in mdb, we used to print both the values of all
> attributes and the values of all live variables. Since some attributes'
> values were given directly by live variables, this lead to some things being
> printed twice. This diff eliminates this duplication.
>
> 2. At user events, we now print the name of the event. Whether we print the
> other stuff we also print at events (the predicate containing the event,
> and its source location) is now controlled by a new mdb command,
> "user_event_context".
>
> 3. We would like different solvers to be compilable independently of one
> another. This means that neither solver's event set should depend on the
> existence of the events needed by the other solvers. This diff therefore
> eliminates the requirement that all modules of the program be compiled with
> the same event set specification. Instead, a program may contain modules
> that were compiled with different event sets. Each event set is named;
> the new requirement is that different named event sets may coexist in the
> program (each being used to compile some modules), but two event sets with
> the same name must be identical in all other respects as well (we need this
> requirement to prevent inconsistencies arising between different versions of
> the same event set).
>
> 4. We now generate user events even from modules compiled with --trace shallow.
> The problem here is that user events can occur in procedures that do not
> get caller events and whose ancestors may not get caller events either.
> Yet these procedures must still pass on debugger information such as call
> sequence numbers and the call depth to the predicate with the user event.
> This diff therefore decouples the generation of code for this basic debugger
> infrastructure information from the generation of call events by inventing
> two new trace levels, settable by the compiler only (i.e. not from the
> command line). The trace level "basic_user" is for procedures containing a
> user event whose trace level (in a shallow traced module) would otherwise be
> "none". The trace level "basic" is for procedures not containing a user
> event but which nevertheless may need to transmit information (e.g. depth)
> to a user event. For the foreseeable future, this means that shallow traced
> modules containing user events will have some debugging overhead compiled
> into *all* their procedures.
...
> tests/debugger/user_event_shallow.{m,inp,exp}:
> New test case to test the new functionality. This test case is the same
> as the user_event test case, but it is compiled with shallow tracing,
> and its mdb input exercises the user_event_context mdb command.
>
> tests/debugger/user_event_spec:
> tests/invalid/invalid_event_spec:
> Update these event set spec files by adding an event set name.
>
> tests/debugger/Mmakefile:
> tests/debugger/Mercury.options:
> Enable the new test case.
>
> tests/debugger/user_event.exp:
> Update the expected output of the old user event test case, which now
> prints event names, but doesn't print attribute values twice.
>
> tests/debugger/completion.exp:
> Expect the new "user_event_context" mdb command in the command list.
>
> tests/debugger/mdb_command_test.inp:
> Test the existence of the documentation for the new mdb command.
>
> tests/invalid/Mercury.options:
> Conform to the name change of the --event-spec-file-name option.
You should also run the test suite in a .decldebug grade and check if
any of the expected outputs there need updating.
...
> %---------------------------------------------------------------------------%
> Index: compiler/code_info.m
> ===================================================================
> RCS file: /home/mercury/mercury1/repository/mercury/compiler/code_info.m,v
> retrieving revision 1.335
> diff -u -b -r1.335 code_info.m
> --- compiler/code_info.m 1 Dec 2006 15:03:51 -0000 1.335
> +++ compiler/code_info.m 4 Dec 2006 03:40:45 -0000
> @@ -182,6 +182,10 @@
> %
> :- pred get_layout_info(code_info::in, proc_label_layout_info::out) is det.
>
> +:- pred get_proc_trace_events(code_info::in, bool::out) is det.
> +
> +:- pred set_proc_trace_events(bool::in, code_info::in, code_info::out) is det.
> +
> % Get the global static data structures that have
> % been created during code generation for closure layouts.
> %
> @@ -394,6 +398,9 @@
> % are live and where at which labels,
> % for tracing and/or accurate gc.
>
> + proc_trace_events :: bool,
> + % Did the procedure have any trace events?
> +
s/trace events/user trace events/ in the comment.
The rest looks okay to me. I'm happy for you to commit it (Mark may
wish to comment further when he gets back.)
Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to: mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions: mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------
More information about the reviews
mailing list