I finally got around to playing with slime's stepper. It's not exactly clear how to get this enabled, but what I did was trace some function with :break t. When the debugger starts, I can then use slime to single-step. This works pretty well. However, after I'm done and untrace the function, I still get stepping breakpoints in the function.
How are these breakpoints supposed to be removed?
Also, from the code, it seems that slime inserts stepping breakpoints at all possible locations in a function. Can't it just single-step the way cmucl's native debugger steps by inserting the breakpoint, running, and then removing the breakpoint?
Ray
* Raymond Toy [2010-09-01 00:52] writes:
I finally got around to playing with slime's stepper. It's not exactly clear how to get this enabled, but what I did was trace some function with :break t. When the debugger starts, I can then use slime to single-step. This works pretty well. However, after I'm done and untrace the function, I still get stepping breakpoints in the function.
How are these breakpoints supposed to be removed?
Also, from the code, it seems that slime inserts stepping breakpoints at all possible locations in a function. Can't it just single-step the way cmucl's native debugger steps by inserting the breakpoint, running, and then removing the breakpoint?
As far as I can rememeber, the idea is to insert breakpoints at all those places that are reachable from the current PC in the current function (and where it's save to set a breakpoint). When a breakpoint is hit, all the breakpoints from that "barrier" are removed before giving control to the UI. The next step command will again compute the reachable code points and insert breakpoints before starting executing.
There may well be bugs there. I think if another function is called before hitting a breakpoint and the callee makes some non-local return (typically from debugger) the breakpoints in the caller are not cleared.
Maybe we need to insert some trampoline frame at callsites to remove the breakpoints on non-local exits. Hmm... might be difficult for the local-call variants.
Helmut
On 9/1/10 3:25 AM, Helmut Eller wrote:
- Raymond Toy [2010-09-01 00:52] writes:
I finally got around to playing with slime's stepper. It's not exactly clear how to get this enabled, but what I did was trace some function with :break t. When the debugger starts, I can then use slime to single-step. This works pretty well. However, after I'm done and untrace the function, I still get stepping breakpoints in the function.
How are these breakpoints supposed to be removed?
Also, from the code, it seems that slime inserts stepping breakpoints at all possible locations in a function. Can't it just single-step the way cmucl's native debugger steps by inserting the breakpoint, running, and then removing the breakpoint?
As far as I can rememeber, the idea is to insert breakpoints at all those places that are reachable from the current PC in the current function (and where it's save to set a breakpoint). When a breakpoint is hit, all the breakpoints from that "barrier" are removed before giving control to the UI. The next step command will again compute the reachable code points and insert breakpoints before starting executing.
There may well be bugs there. I think if another function is called before hitting a breakpoint and the callee makes some non-local return (typically from debugger) the breakpoints in the caller are not cleared.
Ok. Let me take a look at this again. I may have selected the slime abort restart. (But that could go and remove all the breakpoints, I suppose.)
Ray
-
Helmut Eller -
Raymond Toy