tracing options

Zoltan Somogyi zs at cs.mu.OZ.AU
Thu Aug 6 17:10:22 AEST 1998


At the moment, the argument of the --trace option, which must be from the set
{none, interfaces, most, all, default}, specifies several aspects of tracing,
and does not allow them to be treated independently. I propose replacing the
--trace option with a set of other options which can be specified
independently. These are:

	--trace-level default	(default; equivalent to none for non-debug
				grades and shallow for debug grades)
	--trace-level none
	--trace-level shallow
	--trace-level deep

A predicate in a module compiled with no tracing never generates trace events.
A predicate in a module compiled with deep tracing always generates trace
events. A predicate in a module compiled with shallow tracing generates events
only if it is called from a module with deep tracing, and even then it
generates only interface events.

	--trace-internal	(default for --trace-level deep)
	--no-trace-internal

With --trace-internal, the compiler generates events internal to a call,
e.g. entry into switch arms, disjunction arms, then parts and else parts;
without it, it doesn't.

This option is only meaningful for --trace-level deep.

	--trace-returns		(default for debug grades)
	--no-trace-returns

With --trace-returns, the compiler generates stack layout information for
labels representing the return points of calls. With this info, the debugger
can access the values of variables in ancestors of the current call; without
it, it can't.

At present you cannot get the compiler to generate layouts for returns
in shallow traced procedures. This is a problem if the shallow traced
procedure calls a deep traced procedure, and while in that deep traced
procedure the user would like to print a stack dump or the values of variables
in an ancestor call. The proposed option would fix this.

This option is meaningful for --trace-level shallow and deep.

	--trace-redo
	--no-trace-redo

With --trace-redo, the interface of model_non procedures includes a REDO port;
without it, it does not.

I am not sure what the default should be, only that shallow and deep should
have the same default. Do most people want the REDO port?

This option is meaningful for --trace-level shallow and deep.

This option is meaningful for --trace-level shallow and deep.

Overall, the present --trace none corresponds to --trace-level none.

The present --trace interfaces corresponds to --trace-level shallow,
--no-trace-returns, --no-trace-redo.

The present --trace most corresponds to --trace-level deep,
--trace-interfaces, --no-trace-returns, --no-trace-redo.

The present --trace all corresponds to --trace-level deep,
--trace-interfaces, --trace-returns, --no-trace-redo.

We can retain --trace as a special option (an option that sets the values
of a bunch of other options), with this or similar semantics (e.g. --trace
maybe shouldn't set --trace-redo one way or the other).

I also want to add a new, mostly developer-only option --trace-optimized.
The default would always be --no-trace-optimized, which at any trace level
other than none disables program optimizations (e.g. inlining) that alter
the trace. With --trace-optimized, this disabling is not done, which helps
me debug code generator bugs that manifest themselves only after e.g. inlining,
without having to do the inlining manually.

Comments, anyone?

Zoltan.



More information about the developers mailing list