[m-dev.] tracing of builtin modules

Ian MacLarty maclarty at cs.mu.OZ.AU
Wed Nov 16 15:37:44 AEDT 2005


I've found a bug in subterm dependency tracking were it breaks when
tracking subterms through calls to type_to_univ.  The algorithm breaks
because type_to_univ calls private_builtin.typed_unify.
private_builtin.typed_unify is never traced, but it calls
std_util.type_of, which is.
This makes the events of std_util.type_of look like their child events
of type_to_univ, which triggers an assertion failure, because the
body of type_to_univ has no calls to type_of.

There are two solutions I can think of to this problem.  The first is
to trace the builtin modules.  However the following comment in 
mercury_compile.m makes me nervous about doing this:

            % Some predicates in the builtin modules are missing
            % typeinfo arguments, which means that execution
            % tracing will not work on them. Predicates defined
            % there should never be part of an execution trace
            % anyway; they are effectively language primitives.
            % (They may still be parts of stack traces.)

Which predicates are missing typeinfo arguments?  unsafe_type_cast?
Would it be possible to not trace just these predicates?

The second solution is to not allow the builtin modules to call
anything in a potentially traced module.  This would mean copying
or moving those predicates in potentially traced modules which are
called from builtin modules to the builtin modules.

I favour tracing the builtin modules, since that would make
the subterm dependency tracking algorithm cleaner and would
also allow subterms to be tracked through calls to predicates
in the builtin modules (at least those not implemented
in foreign code).

mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list