Re: [gforth] Problem using the debugger with recursive calls

[Anton Ertl]

On Mon, Oct 23, 2017 at 12:09:36PM -0400, Brock Jones wrote:
> The GForth debugger is giving me weird results when I'm trying stuff with
> recursion, for example take this factorial word
> 
> : FACTORIAL ( +n1 -- +n2)
>    DUP 2 < IF DROP 1 EXIT THEN
>    DUP 1- RECURSE *
> ;
> 
> 
> If I try 3 dbg FACTORIAL I get
> 
> : FACTORIAL
> Scanning code...
> 
> Nesting debugger ready!
> [ 1 ] 00003
> 7F4E5EC372F0 55ED908EF498 dup            -> [ 2 ] 00003 00003
> 7F4E5EC372F8 55ED908EF1C0 2              -> [ 3 ] 00003 00003 00002
> 7F4E5EC37308 55ED908EF320 <              -> [ 2 ] 00003 00000
> 7F4E5EC37310 55ED908EF0B8 IF             -> [ 1 ] 00003
> 7F4E5EC37340 55ED908EF498 THEN dup       -> [ 2 ] 00003 00003
> 7F4E5EC37348 55ED908EF1F8 1-             -> [ 2 ] 00003 00002
> 7F4E5EC37350 55ED908EF070 FACTORIAL      -> [ 3 ] 00003 00002 00001
> 7F4E5EC37360 55ED908EF218 *              -> [ 2 ] 00003 00002
> 7F4E5EC37368 55ED908EF088 ;              ->  ok
>   ok
> .s <1> 6  ok
> 
> 
> So the debugger makes it seem like when I run 3 FACTORIAL the result should
> be 2, 3 in the stack, which isn't what it should show. If I run 3 FACTORIAL
> without debugging then the result is 6 in the stack.

Confirmed for both Gforth 0.7.2 and the current development version.
I guess that the stepping debugger puts a breakpoint right after the
call to FACTORIAL, and then presents what happens when it first
reaches that breakpoint.  And it then steps to the end of that
instance of FACTORIAL, and then does not reach another breakpoint.  I
wonder if it works as expected for THROW or return-address
manipulations in all cases.

- anton