In your original post, the lines with the ? are likely caused by a missing or incorrect stackframe in the procedure above.
FPC has 2 directives t {$OPTIMIZATION STACKFRAME} and {$STACKFRAMES OFF}
On top of this I do not know what happen for
- asm routines
- build in / compilerproc routines
- (routines in 3rd party dll and the OS kernel will often have no useful stackframe either)
What happens:
If you call a subroutine, the callers address goes on the stack. The debugger will look for it there, this is the only place it can be found.
But the called routine will also use space on the stack for local vars. And the debugger must know how much or it can not find the caller address.
There is a convention (OS dependent) to create a stackframe, by storing the stackpointer before adding locals. This is stored in the BasePointer register, and thus the debugger can find the info.
Some procedures do not do this. And then the debugger gets lost. (Not sure, if/when extra info may get stored in the debug info / Not sure how well gdb would use it).
So if some routine still breaks the stack, find it and check if the above may apply.
------------------
There may be a bug
https://bugs.freepascal.org/view.php?id=34159I am not sure if this affects the interpretation of the stack (just a very wild guess). If it does, try compiling with -al (slower).