Martin
2018-12-03 12:58:01 UTC
With reference to https://bugs.freepascal.org/view.php?id=34159
It *appears* that this issue also happens on Mac, using lldb (so both
lldb and gdb get step-over wrong, with debug info from fpc).
Posts by "bigDan":
http://forum.lazarus-ide.org/index.php/topic,42869.msg303599.html#msg303599
The log he provided shows that
- lldb got a "thread step-over"
- lldb believed to have stopped at the end of step-over (not any other
reason): "stop reason = step over"
- the active thread remained the same. So stepping was done in the
correct thread
- the called subroutine is located at a different address (not inlined)
pc before stepping (in calling code) 0x0000000100059d8e
pc after stepping (in subroutine) 0x00000001002718e8
- the stackpointer was reduced by 8, and the stackframe register was NOT
yet modified.
So the stop was in the prologue ("begin" line of function)
On windows one way to solve the problem was to get rid of .debug_frame info.
It would be interesting to test if that happens on Mac too.
Does anyone know how to strip that info of the app bundle?
Rebuilding with a different version of Fpc or Lazarus may not be useful
for testing. Tiny changes anywhere in the codebase may require a
new/different test case.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.fre
It *appears* that this issue also happens on Mac, using lldb (so both
lldb and gdb get step-over wrong, with debug info from fpc).
Posts by "bigDan":
http://forum.lazarus-ide.org/index.php/topic,42869.msg303599.html#msg303599
The log he provided shows that
- lldb got a "thread step-over"
- lldb believed to have stopped at the end of step-over (not any other
reason): "stop reason = step over"
- the active thread remained the same. So stepping was done in the
correct thread
- the called subroutine is located at a different address (not inlined)
pc before stepping (in calling code) 0x0000000100059d8e
pc after stepping (in subroutine) 0x00000001002718e8
- the stackpointer was reduced by 8, and the stackframe register was NOT
yet modified.
So the stop was in the prologue ("begin" line of function)
On windows one way to solve the problem was to get rid of .debug_frame info.
It would be interesting to test if that happens on Mac too.
Does anyone know how to strip that info of the app bundle?
Rebuilding with a different version of Fpc or Lazarus may not be useful
for testing. Tiny changes anywhere in the codebase may require a
new/different test case.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.fre