Next: Exiting Commands, Previous: Source Location Printing, Up: Debugger
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> 00 gives level 0 plus all argument
variables. Values will only be accessible if the argument variable is
never set and speed is not 3. SBCL allows any real
value for optimization qualities. It may be useful to specify
0.5 to get backtrace argument display without argument
documentation.
11 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. This is
the default.
21 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).
> 22 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.
32 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.
> (max speed space)debug is greater than both speed and space,
the command return can be used to continue execution by
returning a value from the current stack frame.
> (max speed space compilation-speed)debug is greater than all of speed, space and
compilation-speed the code will be steppable (see Single Stepping).
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 Variable Value Availability). 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.
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.