On 24/08/14 16:44, Joost van der Sluis wrote:
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.
Thanks for looking at this - I will try it out. Two things strike me:
1. How about a "slow step" option?
2. Could the compiler add more information to make this easier? Or is it
simply a matter of compiling everything with a stack frame?
Colin
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
