Hi all,
I think I've found a bug while testing the fpdebug-debugger. The line-info for the attached program is not entirely correct, I think.
Here's the generated assembly:
# [12] case i of
movl -12(%rbp),%eax
testl %eax,%eax
jl .Lj10
testl %eax,%eax
jne .Lj10
jmp .Lj9
.Lj10:
.Ll5:
# [18] writeln('hallo');
call fpc_get_output
movq %rax,%rbx
movq $_$PROJECT4$_Ld1,%rdx
movq %rbx,%rsi
movl $0,%edi
call fpc_write_text_shortstr
call FPC_IOCHECK
movq %rbx,%rdi
call fpc_writeln_end
call FPC_IOCHECK
.Lj9:
.Lj5:
call FPC_POPADDRSTACK
.Ll6:
# [20] end;
leaq -24(%rbp),%rdi
call fpc_ansistr_decr_ref
movq -120(%rbp),%rax
testq %rax,%rax
je .Lj6
call FPC_RERAISE
.Lj6:
movq -128(%rbp),%rbx
leave
ret
As you can see, according to the line-info the call to FPC_POPADDRSTACK belongs to the writeln. But the jump in the case goes to label Lj9.
Imaging stepping through this procedure. When the writeln is skipped, the 'call fpc_popaddrstack' is the next command. And the debugger will think that the 'writeln' is the current command. (ie: the debugger jumps from line 12 to 18. Even if line 18 is never executed)
Gdb does not show this. I think because it also checks if the current instruction pointer is at the start of the line as given in the debug info. FpDebug also does that check in some cases, but not in this case since it should not be necessary. At least so I thought.
I can add this check to the debugger anyway, but am I right that the line info in the example is wrong? Then I can try to fix it.
Joost.