[Lazarus] Need testers for the a new debugger

[Joost van der Sluis]

On 07/21/2014 10:11 PM, C Western wrote:
> 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.

Solving this particular problem was easy, but debugging your 
test-application opened a whole new can of worms.

I've re-written the step-into-line code completely. It's not fool-proof, 
but at least it works stepping into a procedure one level deep. (That 
means: if the procedure being called has debug-info.) If it does not 
have debug-info but another procedure with debug info is called 
further-on, it will probably work.

The problem lies in functions that do not set the stack-frame. Among 
those are the compiler-procedures. If two of those are called after each 
other, the debugger can loose track...

So, please test. I'm convinced that a solution that always works and is 
also reasonable fast is impossible. (gdb also makes comparable mistakes)

Oh, and I added re-direction of the console in- and output to the 
console-debug screen.

Joost.