Next: Exiting Commands, Previous: Source Location Printing, Up: The Debugger [Contents][Index]
The compilation policy specified by optimize
declarations affects the
behavior seen in the debugger. The debug
quality directly affects the
debugger by controlling the amount of debugger information dumped. Other
optimization qualities have indirect but observable effects due to changes in
the way compilation is done.
Unlike the other optimization qualities (which are compared in relative value
to evaluate tradeoffs), the debug
optimization quality is directly
translated to a level of debug information. This absolute interpretation
allows the user to count on a particular amount of debug information being
available even when the values of the other qualities are changed during
compilation. These are the levels of debug information that correspond to the
values of the debug
quality:
0
Only the function name and enough information to allow the stack to be parsed.
> 0
Any level greater than 0
gives level 0
plus all
argument variables. Values will only be accessible if the argument
variable is never set and
speed
is not 3
. CMUCL allows any real value for optimization
qualities. It may be useful to specify 0.5
to get backtrace argument
display without argument documentation.
1
Level 1
provides argument documentation
(printed arglists) and derived argument/result type information.
This makes describe
more informative, and allows the
compiler to do compile-time argument count and type checking for any
calls compiled at run-time.
2
Level 1
plus all interned local variables, source location
information, and lifetime information that tells the debugger when arguments
are available (even when speed
is 3
or the argument is set.) This is
the default.
> 2
Any level greater than 2
gives level 2
and in addition
disables tail-call optimization, so that the backtrace will contain
frames for all invoked functions, even those in tail positions.
3
Level 2
plus all uninterned variables. In addition, lifetime
analysis is disabled (even when speed
is 3
), ensuring
that all variable values are available at any known location within
the scope of the binding. This has a speed penalty in addition to the
obvious space penalty.
As you can see, if the speed
quality is 3
, debugger performance is
degraded. This effect comes from the elimination of argument variable
special-casing (see debug-var-validity.) Some degree of
speed/debuggability tradeoff is unavoidable, but the effect is not too drastic
when debug
is at least 2
.
In addition to inline
and notinline
declarations, the relative values
of the speed
and space
qualities also change whether functions are
inline expanded (see inline-expansion.) If a function is inline
expanded, then there will be no frame to represent the call, and the arguments
will be treated like any other local variable. Functions may also be
“semi-inline”, in which case there is a frame to represent the call, but the
call is to an optimized local version of the function, not to the original
function.
Next: Exiting Commands, Previous: Source Location Printing, Up: The Debugger [Contents][Index]