[m-dev.] for review: new method of handling failures, part 1 of 6

Zoltan Somogyi zs at cs.mu.OZ.AU
Fri Jul 3 14:56:31 AEST 1998


> > runtime/mercury_engine.c:
> > runtime/mercury_wrapper.c:
> > 	Put MR_STACK_TRACE_THIS_MODULE at the tops of these modules, so that
> > 	the labels they define (e.g. do_fail and global_success) are registered
> > 	in the label table when their module initialization functions are
> > 	called. This is necessary for a meaningful nondet stack dump.
> 
> A quick question: this isn't going to cause mercury_trace.o to be linked in,
> is it? (I don't think it will, I just want to be sure.)

No, it won't. It only causes the generation of the stack layout structures for
these modules, and the registration of those layout structures in the label
table.

> > compiler/llds_out.m:
> > 	Emit a #define MR_USE_REDOFR before including mercury_imp.h, to
> > 	tell the runtime we are using the new failure handling scheme.
> > 	This effectively changes the grade of the compiled module.
> 
> Hmm, what about the code in runtime/*.c, will that get MR_USE_REDOFR defined?

Not by this mechanism.

> If so, how?

I do it by including EXTRA_CFLAGS = -DMR_USE_REDOFR in Mmake.stage.params.
After committing this, we will need to do the same for the workspaces used
by the nightly scripts. When the change is installed on a machine, people
with workspaces on the machine will need to include set EXTRA_CFLAGS in their
Mmake.param when they recompile everything. When it is installed on everything,
we can put #define MR_USE_REDOFR at the top of mercury_imp.h.

I told you the switchover would be complex.

The change to llds_out is to force a *visible* as opposed to an invisible error
if this somewhat complex protocol is violated.

Zoltan.



More information about the developers mailing list