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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
