frames, stacks, traps, continuations, backtraces, oh my oh my.

[Andy Wingo]

Hey folks,

Over the weekend I started to work on tidying up some loose ends in the
vm branch. One of the big loose ends is the debugging story: getting
good backtraces between interpreted and compiled code, etc. My mind is
ajumble with code right now, but I figured I'd dump some observations,
to see if they jog any neurons in anyone's head.

 * make-stack with an outer cut that is inside vm-compiled code will not
   find the outer cut, thus it returns no frames.

 * It is insane to have VM compilation affect the general debugging
   interface -- the primitives that the we provide already (make-stack
   and start-stack, operating either on the current or a captured
   continuation) are a bit goofy, but they have well-defined and
   sufficient semantics.

 * Calling scm_backtrace() should show backtraces regardless of whether
   the code is running interpreted or compiled.

 * It is truly irritating to have to deal with stacks.[ch] and
   debug.[ch].

 * It is a bit distressing to have to shoehorn my beautiful vm-frame
   stuff into the old stack and debugging infrastructure. Perhaps things
   can be made nicer on the C side.

 * "Info frames" are what are contained in a #<stack> object; they are
   copies of information from a real continuation. Backtraces rely on
   this information only, not the live information.

 * "Debug frames" are two things: (1) a chain of data structures on the
   C stack, describing "frames" in a continuation; (2) Scheme objects
   that point to those C structures. The Scheme objects only make their
   way into scheme as the result of a "trap", a low-level hook run by
   the evaluator. The latter are sometimes called debug objects.

 * Debug frames aren't there if you aren't using the debugging
   evaluator.

 * Debug objects (on the Scheme side) need to be cheap to create,
   otherwise running code with traps enabled would be quite slow. For
   that reason we can't operate on full continuations, given how
   continuations are implemented.

 * Perhaps apropos the former, did I mention that debug.h sucks?

 * As yet unpushed, the VM has an abstraction similar to debug objects,
   but more pleasant to work with. Since debug objects aren't used
   except as arguments to make-stack, maybe I can avoid them entirely.

Actually, the last point is convincing me. Also, the tea is convincing
me to go to sleep. Perhaps finally the code can come together later this
week.

Thanks for listening, it's been helpful to me ;)

Andy
-- 
http://wingolog.org/