[Lazarus] Need testers for the a new debugger

[C Western]

On 21/07/14 12:44, Joost van der Sluis wrote:
>  > On 20/07/14 15:47, Joost van der Sluis wrote:
>  > I haven't seen the spurious SIGSEGV for a while, so maybe that is fixed.
>  > I am still seeing the spurious leaving of a routine on pressing step
>  > into on one particular begin, but mostly it looks good - I think it is
>  > rather faster than the gdb debugger.
>
> It's not that strange it's faster then the gdb-debugger, as gdb is an
> external application from which the output is parsed.
>
> The step-into-next-line code is quite complicated. Just single-stepping
> until another procedure with line-info has been hit is too slow. So it
> uses watchpoints on the stack, so that the debuggee stops when a new
> procedure is being called, or the current procedure has ended. Then it
> compares the line-info with the line-info at the start of the
> step-into-next-line. It is very well possible that for some reason the
> start of the procedure is ignored, so that it immediately steps to the
> end of the procedure.
>
> Can you create a small test-application with a procedure that has this
> problem? With some steps to reproduce?


Managed to create a small test program:

program tproj;

uses sysutils;

procedure a(const s: string);
var
   a: string;
   r: array [0..10] of Double;
begin
   a := s+s+s;
   r[8] := StrToFloat(a);
   WriteLn(a, ' ', r[8])
end;

begin
   a('6'); <<-Set break point here, and hit step into here twice
end.

First step into ends on begin in procedure, second on final end.
Seems to be related to size of stack frame - if I didn't have the array 
in, it works as expected. I compiled it with all stack checks on.

I know this stuff can be difficult - I have certainly seen some odd 
things with Delphi and gdb. My hope is we can resolve some of these 
things as we now have control over all parts of the system.

Colin