guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Debugging plans


From: Neil Jerram
Subject: Debugging plans
Date: 28 Jun 2001 22:44:17 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

I have a plan for improving Guile's Scheme-level debugging abilities
and would like to run it by you.  (See thread in guile-user for some
background.)

We already have the debugger (ice-9/debugger.scm), which you can enter
by typing (debug) after an error has occurred, and it allows you to
examine the stack trace and values of variables at all stack depths.

The only thing missing is "breakpoints" - i.e. somehow specifying a
place where you want to drop into the debugger, and then continuing
execution from that point once you've finished messing with it.
Temporary breakpoints, next, step, finish, and watchpoints can all be
seen as special cases of breakpoints.

I think a nice general way of specifying a breakpoint is a procedure
that gets the current stack and can decide, by examining that stack,
whether to drop into the debugger, display some variable, etc.  So the
signature for such procedures is (lambda (stack) ...).

This allows for many kinds of breakpoint specification, for example

(define (in proc)
  (lambda (stack)
    (if (eq? (frame-procedure (stack-current-frame stack)) proc)
        (debug-stack stack))))

(define (at file line)
  (lambda (stack)
    (let ((source-properties (... stack)))
      (if ... ; file and line match those in source-properties
          (debug-stack stack)))))

(define (watch expr)
  (let ((last-value #f))
    (lambda (stack)
      (let ((value (eval expr)))
        (or (equal? value last-value)
            (begin
              (set! last-value value)
              (debug-stack stack)))))))

(Perhaps it would be better if these procedures simply returned non-#f
to indicate that their caller should then do (debug-stack stack); this
way the procedures could be logically composed.)

To link such procedures with the evaluator traps mechanism, I propose
to change the current apply-, enter- and exit-frame-handlers to hooks
(defined in C and visible from Scheme) to which users can add such
procedures using add-hook!.  (Hmm... not sure exactly what the
parameter list should be for these hooks; currently the handlers are
given more than just a debug object - do they need the other
parameters?)

Things like gdb's `tb +1' could be done by adding a hook procedure
that automatically removed itself after being called once.  Does
anyone know how to implement a hook procedure that can remove itself?
Similarly `step 5' would carry a counter, not do anything the first 4
times, and then remove itself after calling into the debugger on the
5th time.

All and any thoughts on this would be very much appreciated!

        Neil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]