Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2018-12

wrong step-over with fpc debug info / how to do objcopy on Mac, or strip .debug_frame

2 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Martin

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.

Reply by email

Jonas Maebe
to Martin
Martin wrote 18 lines
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.

At best it hides an apparent bug FPC's generation of Dwarf CFI.

It would be interesting to test if that happens on Mac too. Does anyone know how to strip that info of the app bundle?

FPC does not generate any information that gets stored in .debug_frame on Darwin. The section that is there probably comes from crt1.o or so, and does not cover FPC-generated code.

Jonas

Reply by email