save/relocate/restore call stack or coroutine?

[stsp <stsp2@yandex.ru>]

Hi!

Purely theoretical question here. :)
Many people, including myself, keep
falling into this trap:
https://www.reddit.com/r/cpp/comments/eewqwc/serializable_coroutines_in_c_gameplay_code/
Which is that they take the fibers/coroutines
to implement some logic with wait/blocking
capability, and, because there is a state
object (eg ucontext_t) and an explicitly
allocated stack frame, they expect to be
able to save/restore it along with any other
save data.

I believe this even worked in some limited
scenarios in pre-ASLR era, but today they
face the fact that the call stack needs to
be somehow "relocated" to be loaded on
a different process.

I looked around to see what gcc technologines
are available to help with that, and what I've
found, is:

- backtrace() can be used to identify all
return addresses on stack, and to patch
them up.
- Named address spaces __seg_fs, __seg_gs
can be used to make some pointers relocation-
friendly.
Unfortunately there seem to be no way to
build the entire compilation unit with __seg_fs
being a default address space, and also there
seem to be no conversion between __seg_fs
and normal pointers (by adding/subtracting
rdfsbase on a conversion).
- Stack maps:
https://www.mail-archive.com/gcc@gcc.gnu.org/msg77319.html
were considered too difficult to implement:
https://www.mail-archive.com/gcc@gcc.gnu.org/msg77317.html
and AFAICS are still not implemented.
They could help to identify all pointers
to heap objects and relocate them, but I
wonder if they are only considered for
strongly-typed languages, and not for
C/C++.


So the question is: how realistic is to
expect that the call stacks would be
saveable/relocatable one day? How
far are we from that point? It looks like
all the needed technologies already
either exist or at least are considered
for an implementation. Or am I missing
much more unsolvable problems?
Or maybe there is already some other
way of doing that? :)