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? :)
