[armedbear-devel] [rfc] Preventing stack inconsistencies - structurally

[Mark Evenson]

On 12/31/10 4:30 AM, Alan Ruttenberg wrote:
[…]

> b) If you are going to be doing thinking about compiler architecture I
> would very much like to see some thought going into debuggability. My
> current impression is that the trend is downward with more and more
> cases of not even being able to see function call arguments in slime.
> For example, at this point in ABCL's development, I think having a
> compiler option that pays performance for the ability to view local
> variables in the debugger should be an increasing priority. Other's
> mileage may vary, but in my case, where the bulk of time is spent in
> java libraries of various sorts, improving lisp performance is a
> distinctly lower priority than improving developer productivity by
> making it easier to debug.

Improving the ability to debug code is the main point is one of my main 
concerns as well.   It is indeed good to know that this point of view is 
shared within the ABCL user community, and rest assured that I will 
continue to advocate/promote this line of thought in the development 
discussions on #abcl.

Steps in the direction of better debug facilities for ABCL that I have 
in mind would be 1) the ability to inspect local variables from a given 
stack frame (probably by implementing EVAL with respect to a given 
frame, 2) implementing STEP, 3) the ability to restart computation at a 
given frame, and 4) better integration with source location information 
like the necessary hooks to support XREF.  I have no concrete plans for 
implementation yet, as I am just trying to analyze what would be 
involved.  Any others out there on private wishlists?

Currently I am investigating how to do these things in interpreted mode 
as it seems to be the easier path, and being able to do debug things 
would greatly assist the construction of a corresponding compiler.  The 
one exception to the observation that we should try to do these debug 
implementation in interpreted mode first, is it might be possible to 
implement STEP in compiled code via "native" JVM breakpoints, but this 
would entail outfitting the compiler with a much better mapping of 
source to object code (and might involve using one JVM to instrument a 
second one via JVMTI).  This "source to object" mapping in the compiler 
seems to be needed in general, as it would allow (eventually) things 
like finding the value of a local variable in compiled mode and to debug 
the compiler behavior as was needed in the current problem with ticket 
#117 that I asked Erik to help out with in order to get callbacks 
working in JNA.

I have fought hard to prevent regressions in information present in 
SLIME.  Are you observing the complete lack of all function call 
arguments in the SLIME debugger presentation?  If so, we should debug 
your installation details a bit, as SLIME HEAD with ABCL trunk always 
should work as it's what I test with.  In order to prevent the pretty 
printer's elision of frame arguments, I often have to set 
*PRINT-RIGHT-MARGIN* to some large finite value, but I assume you would 
have recognized this.  The compiler also often optimizes away stack 
frames that can be restored quickly by interpreting the given form at 
the current point in SLIME via M-x slime-eval-defun.  Please provide 
some more details when you get the chance.

ABCL: arming bears since 1997!

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."