[fpc-devel] A little something I've been working on...

[Martin Frb]

On 21/02/2026 19:26, Graeme Geldenhuys via fpc-devel wrote:
> On 2026-02-21 17:36, Martin Frb via fpc-devel wrote:
>> My earlier point on "stack resolution" wasn't fully answered though.
>> How to you encode: How to find the address of the parent stack frame?
>
> You raise a valid point. My current implementation relies on frame
> pointers (RBP chain) being present -- [RBP] gives the parent frame,
> [RBP+8] gives the return address. This works reliably for FPC-compiled
> x86/x86_64 code because FPC generates frame pointers for all functions
> by default, and you only lose them with explicit -Oo optimisations,
> which are uncommon in debug builds.

Actually, no you are wrong (technically correct, but...).
E.g. if you stop at an assert or exception.

Then you are in RTL code => Many people using Lazarus, use the prebuild RTL.
That prebuild RTL is O2 (and without debug info, so encoding stack in 
debug info wont help in this case).

But a common issue, that we had for a very long time was, that when you 
stopped in such an exception, in a way that
procedure ButtonClick(...); // or really any code of yours
begin
   SomeCall to RTL; // not all, but some
end;

Then the stack would be
0: raise
1: somecall
2: Caller_of_ButtonClick

But ButtonClick wasn't in there, because "somecall" did not have a 
stackframe. which means RBP still had the value of ButtonClicks 
stackframe. But RIP of course is in SomeCall.
Resolving from that RBP would of course go to the caller of ButtonClick 
(because its the frame for ButtonClick, and if you get the caller from 
that....)

Though of course, this issue can't be completely solved in debug info, 
because as I said => Somecall doesn't have any.