[Openmcl-devel] debugging help

[Gary Byers]

On Sat, 8 Feb 2003, bryan o'connor wrote:

> are there any docs available on how to use the debugger,
> set breakpoints, step, etc?  openmcl is my first exposure
> to lisp; my only debugging experience is with c/c++.
>
> i'm trying to debug some code that fails with the error
> that a value is not of an expected type and i'd like to
> watch the code at that point to see why it's expecting
> what it is and why it's not getting it.
>

TRACE is the low-tech way of observing what arguments a
function is called with and what values it returns.

The low-tech equivalent of a breakpoint is to insert a
call to BREAK at strategic points in the program.

MCL and OpenMCL support some extensions to TRACE.  I started
to write a description of them, then realized that I'd hardly
ever used them and had to read the source (carefully) before
I could remember what they did.  It's a good thing that
Google is only a few mouse clicks away:

<http://www.cc.gatech.edu/computing/classes/cs2360/ghall/tools/MCL/mcl_trace.html>

has a good synopsis of the extended TRACE options that MCL/OpenMCL
support.

STEP generally only works on interpreted code, and by default
everything's compiled in MCL/OpenMCL.  (The full-blown interpreter
exists for the sole purpose of supporting the stepper.)

More accurately, the stepper will step through functions if it
can get its hands on an equivalent lambda expression;  If you
want to use STEP on one or more functions, you need to either:

a) Set the global variable CCL:*COMPILE-DEFINITIONS* to NIL
   before defining the functions you want to step throuugh, or

b) Set the global variable CCL:*SAVE-LAMBDA-EXPRESSION* to T
   before defining those functions.

The latter approach is probably more convenient, but it may
not work (if the functions were defined in a non-null lexical
environment or if macro definitions that were available at
compile-time are missing at "step time".)

The fact that the stepper only works on interpreted code may
mean that it's hard to use it to debug large, complicated
programs.

This is certainly a less sophisticated debugging environment
than most C IDEs provide.  I'm not sure that that necessarily
means that one is less productive when using low-tech tools
(TRACE, BREAK, and FORMAT) in a CL environment.


> also in a backtrace listing, what's the third bit of
> info displayed?  i assume the first two are frame number
> and function name.

The OpenMCL backtrace is sort of the backend of the GUI backtrace
dialog that MCL provides; the third item is the program counter (the
offset of the current instruction in the function from the start of
the function).  MCL's backtrace dialog offers the option to
disassemble the code around the PC in a selected frame.

>
> thanks!
>

MCL's manual (which describes a lot of this stuff) isn't
LGPL'ed;  a lot of environmental things that are similar or
identical between the implementations need to be documented
redundantly.

> 				...bryan
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel