[m-dev.] for review: a big step towards the trace-based debugger (part 1 of 3)

[Zoltan Somogyi]

> > > +			maybe(label),	% name of the label of the call event
> > >  		).
> > 
> > Ditto here: I don't know what "the label of the call event" means.

In the new design, each tracing event has a label associated with it.
The stack layout for that label records what variables are live and where
at the event. These labels are generated for the event; there is no sharing,
except that some of these labels may be fallen into from other places
and thus optimization may redirect references from another label to one
of these labels. This cannot happen in the opposite direction, due to
the reference to each event's label from the event's pragma C code instruction.
(This prevents labelopt from removing the label, which is why I put in the
reference.)

I will make the comment to this effect in trace.m more detailed and prominent.

> > > compiler/continuation_info.m:
> > > compiler/stack_layout.m:
> > > 	Do not associate the stack layout information at procedure entry and
> > > 	exit with the per-procedure data structure. Since we now associate this
> > > 	info with the labels of those events instead, they do not need special
> > > 	handling. However, do include a pointer to the call event's label's
> > > 	layout structure in the per-procedure data, so that we can later
> > > 	implement redo in the debugger.
> > 
> > When you say the "call event's label", do you mean the entry label?

No. No event will ever have the entry label as its associated label.

> Indeed, since the layout infos are used for multiple purposes (only one
> of which is tracing), it would be best to avoid "event" as much as
> possible.

The only purpose of THAT SLOT in the stack_layout IS for tracing, and the
label it points to has no meaning except to record the state of variables
at the time of the call event, so it would be pointless to avoid using "event"
in this case.

Zoltan.