The easiest way to see the communication is to open: menu View> Ide Internals > Debugger Output
On mac, you may need to resize the window, if the memo scrambles the text....
Compile the IDE with -dDBG_WITH_DEBUGGER_DEBUG and the window allows sending commands to lldb. However sending step commands can hang the debugger, as internal state is not kept for those commands.
This function is only tested with gdb, and was designed for data inspection. But you can try....
The 2nd way to watch, is to start the IDE from console and use the --debug-enable (from the start of this thread) => the output goes to console.
Or use --debug-log=file and tail the file
Actually you only need --debug-enable=DBG_CMD_ECHO the other flags show other info. (like state changes of the internal debugger object).
The code for dealing with stepping is in the package LazDebuggerLldb (it is the same with/without fpdebug)
unit LldbInstructions, contains mini-objects for each instruction and receiving the response.
unit LldbDebugger is in control of triggering them, and dealing with the result.
The IDE calls TLldbDebugger.RequestCommand
which then calls TLldbDebugger.LldbStep
which creates a TLldbDebuggerCommandRunStep.Create object
This is queued and when the queue get to it, it calls TLldbDebuggerCommandRun.DoExecute
DoExecute will be called twice: First goes to DoInitialExecute, and then goes to TLldbDebuggerCommandRun.ResumeWithNextStepCommand
This creates TLldbInstructionProcessStep.Create and sets the finished handler to RunInstructionSucceeded
However the actual code flow resumes in TLldbDebuggerCommandRun.DoLineDataReceived
A lot of the code deals with what happens if you step over an exception.
If you do (eg step over a procedure that raises an exception) then the breakpoint at fpc_raise_exception is hit, the debugger will stop at that breakpoint, and the step is interrupted.
If the particular exception is ignored that is handled, and the IDE calculates where the step should have ended.
If there is no exception then it should read (in several calls to that method) the stop/stopped messages from lldb, and exit the command after setting the debuggerstate, and calling Finished.
------------------------
It may be possible to detect, if stepping ends inside a sub-function, and maybe get back to the main method in the same way this is done for exception (except you would not need to check for pop_exception, until you actually encounter an exception...
https://bugs.freepascal.org/view.php?id=34159I don't know what tools there are on Mac for this. But if there is a possibility to strip away, or prevent certain sections of the debug info....
On windows it appears that this helps: objcopy.exe -R .debug_frame project1.exe project1n.exe
Removing a section called ".debug_frame"