[m-dev.] debugging grades and I/O tabling

[Mark Brown]

On 30-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 30-Aug-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> > I am more optimistic than that.  In fact, I can't at the moment foresee
> > any problems with the following (I still need to think about it some more,
> > though):
> > 
> > We produce, in addition to the existing events, just the following (hidden)
> > events:
> > 
> > 	- cond, then, else
> > 	- nege, negs, negf
> > 	- first_disj, later_disj
> > 
> > The first two groups provide information that we need to interpret the
> > annotated trace correctly.  The disj events are not really necessary, but
> > can help to prune some questions that are irrelevant because they have been
> > backtracked over.
> 
> The existing events above mean the interface events.

No, they mean the interface events of procedures whose nearest traced
ancestor is deep traced (or greater).  Procedures in shallow traced modules
which (a) are not exported, and (b) do not have their address taken, should
never need to generate interface events.

> Consider the library. Since we compile it with --trace minimum, which means
> it is compiled with shallow tracing in debug grades, we trust the entire
> library. Yet cross-module calls in the library still incur the overhead
> not just of a call to MR_trace but also (since MR_trace_enabled is true)
> of the check of the MR_trace_from_full. If we add hidden events, it will
> incur this overhead on many more events. If we compiled the whole library
> with interface tracing, we wouldn't need these extra events, and the overhead
> would be significantly smaller (the MR_trace_enabled check would fail, so we
> wouldn't even get to the MR_trace_from_full check).

I agree that this optimization has significant benefits.  But I think that,
as with any other optimization, we shouldn't apply it unless we know it
to be safe.  If one of the dependant modules is compiled with full tracing,
then I'm contending that this optimization is not safe, because it ignores
the assertion by the programmer that the dependant module should not be
trusted.

If we were to make this optimization safe for procedural debugging (e.g.
by doing some sort of analysis) then, yes, I agree it would be good to
also do this for declarative debugging.  But we currently have no way of
checking that it is safe.

> Trusting entire libraries is certainly something that people frequently
> wish to do, and being able to use that to reduce debugging time strikes me
> as worth while. Why are you saying "no, people couldn't possibly want that,
> and if they do want that they are wrong"?

If they assert that a dependant module should not be trusted by passing the
'--trace decl' option to it, and we trust that module by not generating events
for it, then I'm afraid that it would be us who are wrong rather than them.

> 
> > > If we offer both shallow tracing and interface tracing, users can choose
> > > interface tracing if they trust that module and all the modules that it
> > > depends on, or they can choose shallow tracing if they trust that module only.
> > > Do you have a problem with this?
> > 
> > Yes.  Users can effectively make inconsistent assertions: they may compile
> > a module with interface tracing but compile one of its dependencies with
> > full tracing.
> 
> Whether that is or is not an inconsistency depends on what assertion you see
> shallow tracing as making.
> 
> If the assertion is "I trust this module", then there is no inconsistency:
> the assertions made by both kinds of tracing simply add to the set of trusted
> modules. There can be inconsistency only if the assertion is "I trust this
> module, but I definitely do not trust the modules it depends on, except the
> ones I trusted by compiling them with shallow tracing".
> 
> Why do you think it natural for programmers to state "I do not trust module A"
> by compiling module B (which calls module A) with shallow tracing?

I don't.  I think it is natural for programmers to state "I do not trust
module A" by compiling module A with deep tracing (or greater).

(Incidentally, I called it 'full' tracing above, by which I meant deep
tracing or greater.  My example of inconsistency didn't refer to shallow
tracing at all.)

 Is the
> trace level with which the programmer compiles module A itself not a more
> direct indication?

Precisely.  In particular, compiling module A with deep (or greater) tracing
is a direct indication that the module shouldn't be trusted.

 And if you accept that programmers should be able to state
> "I do not trust module A" with the trace level of module B, why are you
> against the programmer being able to say "I trust module A, at least when
> called from module B" by specifying interface tracing for module B?

Since when does the level of trust in a module depend on who is calling it?
Either you trust it, or you don't.

Cheers,
Mark.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------