[gambit-list] C stack frames need to be returned in exactly the same order they were created Re: FFI and threads: abrupt exit 71
vyzo at hackzen.org
Sun Feb 24 20:12:40 EST 2013
On Sun, Feb 24, 2013 at 4:25 PM, Mikael <mikael.rcv at gmail.com> wrote:
> Neat! Are you aware of any good example code for this anywhere?
You can read the glibc sources for some general techniques in
implementing userland context switching -- check the code for
setjmp/longjmp and the *context family
If you want to see a full threading system using these techniques, check
the source for gnu pth.
If I get around polishing my hack enough to be more generally useful,
I can post it to the list.
> 2013/2/25 Dimitris Vyzovitis <vyzo at hackzen.org>
>> On Sun, Feb 24, 2013 at 2:25 PM, Patrick Li <patrickli.2001 at gmail.com>
> Same here - are you aware of particularly good documentation or use examples
> on it?
For handling stack overflows, man mmap, mremap and mprotect.
The basic idea is mmap your stack, mprotect your bottom pages and
install a segfault handler with SA_SIGINFO (man sigaction) so that you
get the context at the handler. You can find the exact address of the
fault in the siginfo struct (si_addr), verify that it is indeed a fault in your
redzone and then you can remap (or throw your hands in the air and
You can also jump out of the signal handler and manipulate execution
context using the ucontext_t you get as third argument.
Note that the context is live -- it is stored by the kernel just under
handler frame. So any changes you make to the registers there will be live
in the process once you exit the handler.
You will also want to use sigaltstack (man sigaltstack) to setup an
alternate stack for your signal handler, so that it doesn't double
For segmented stacks check the gcc implementation;
keywords: gcc split stacks
Hieb/Dybvig's classic cactus stack paper may also be of interest
(Representing control in the presence of first-class continuations.)
More information about the Gambit-list