Sign in Join

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

Mailing lists / fpc-pascal / 2019-11

get_caller_frame

7 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

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

Ryan Joseph

I came across get_caller_frame in some unrelated code and I was just curious about this so I wanted to ask.

What does get_caller_frame return exactly? Is this a pointer to a stack frame that could be copied to the heap? I'm still interested in how we could add some form of coroutine like behaviors to pascal and so I was wondering if we could copy/restore the current stack pointer so that SetJmp and LongJmp would not blow things up.

Regards,
Ryan Joseph

Reply by email

Sven Barth
to Ryan Joseph

Ryan Joseph via fpc-pascal schrieb am
Mi., 20. Nov. 2019, 04:36:

Show quoted text 9 lines
I came across get_caller_frame in some unrelated code and I was just curious about this so I wanted to ask. What does get_caller_frame return exactly? Is this a pointer to a stack frame that could be copied to the heap? I'm still interested in how we could add some form of coroutine like behaviors to pascal and so I was wondering if we could copy/restore the current stack pointer so that SetJmp and LongJmp would not blow things up.

It returns the address of the caller's frame pointer. See also https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html

It's mainly used in context of raising exceptions with the help of a second function. See here:
https://freepascal.org/docs-html/current/ref/refse112.html#x227-24900017.1

Regards,
Sven

Reply by email

Florian Klämpfl
to Sven Barth
Sven Barth wrote 20 lines
Ryan Joseph via fpc-pascal < > schrieb am Mi., 20. Nov. 2019, 04:36: I came across get_caller_frame  in some unrelated code and I was just curious about this so I wanted to ask. What does get_caller_frame return exactly? Is this a pointer to a stack frame that could be copied to the heap? I'm still interested in how we could add some form of coroutine like behaviors to pascal and so I was wondering if we could copy/restore the current stack pointer so that SetJmp and LongJmp would not blow things up. It returns the address of the caller's frame pointer. See also https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html It's mainly used in context of raising exceptions with the help of a second function. See here: https://freepascal.org/docs-html/current/ref/refse112.html#x227-24900017.1

For the record: the reliability of this function is limited, in particular in combination with optimization.

Reply by email

Ryan Joseph
to Sven Barth: Ryan Joseph via fpc-pascal schrieb am Mi., 20. Nov. 2019, 04:36: It returns the address…
Show quoted text 6 lines
On Nov 20, 2019, at 1:56 AM, Sven Barth via fpc-pascal wrote: It returns the address of the caller's frame pointer. See also https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html It's mainly used in context of raising exceptions with the help of a second function. See here: https://freepascal.org/docs-html/current/ref/refse112.html#x227-24900017.1

I guess I don't know what a frame pointer is. I thought it meant a pointer to the current stack frame and so I was curious if the RTL could include a way to copy the stack with the pointer and restore it later. Is that not how it works?

Regards,
Ryan Joseph

Reply by email

Sven Barth
to Ryan Joseph
Ryan Joseph wrote 8 lines
> On Nov 20, 2019, at 1:56 AM, Sven Barth via fpc-pascal wrote: > > It returns the address of the caller's frame pointer. See also https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html > > It's mainly used in context of raising exceptions with the help of a second function. See here: https://freepascal.org/docs-html/current/ref/refse112.html#x227-24900017.1 > I guess I don't know what a frame pointer is. I thought it meant a pointer to the current stack frame and so I was curious if the RTL could include a way to copy the stack with the pointer and restore it later. Is that not how it works?

No. On x86 it's essentially the content of the EBP/RBP register which is (assuming no optimizations are done) essentially the ESP/RSP register of the calling function. This is only used by the exception handling to have the exception appear to be raised somewhere else.

The exception handling itself does not need it. The generic mechanism for example is a stack of exception frames (both except- and finally-blocks) and the exception handling code calls the handlers from top to bottom (thus executing explicit destructors (bla.Free) and implicit reference count decreases) before restoring the state using LongJmp (which also restores the original stack pointer register). The SEH and PSABIEH mechanisms that FPC supports work in a similar way (e.g. the SEH on Win32 is a single linked list).

Regards,
Sven

Reply by email

Ryan Joseph
to Sven Barth
On Nov 21, 2019, at 1:41 AM, Sven Barth via fpc-pascal wrote: No. On x86 it's essentially the content of the EBP/RBP register which is (assuming no optimizations are done) essentially the ESP/RSP register of the calling function. This is only used by the exception handling to have the exception appear to be raised somewhere else.

So what's missing then to be able make saving a stack frame to the heap and then restoring it?

Regards,
Ryan Joseph

Reply by email

Sven Barth
to Ryan Joseph

Ryan Joseph via fpc-pascal schrieb am
Fr., 22. Nov. 2019, 01:51:

Show quoted text 13 lines
> On Nov 21, 2019, at 1:41 AM, Sven Barth via fpc-pascal < > wrote: > > No. On x86 it's essentially the content of the EBP/RBP register which is (assuming no optimizations are done) essentially the ESP/RSP register of the calling function. This is only used by the exception handling to have the exception appear to be raised somewhere else. So what's missing then to be able make saving a stack frame to the heap and then restoring it?

That the compiler doesn't throw a wrench in your plans and decides to use EBP/RBP for its own purposes due to optimization? Not to mention that on other platforms this will likely be completely different?

Regards,
Sven

Reply by email