[M3devel] User-level threading

Elmar Stellnberger elmstb at aon.at
Wed Jul 4 20:12:04 CEST 2007

 Not long ago I have fixed this problem by replacing setjmp/longjmp with
my own i386 - implementations of these functions for SRC-M3. The result
seems to be stable and correct.
However this may be less favourable than using makecontext since the
assembler routines will only work on i386 hardware.
Moreover setjmp/longjmp are said that they may cause the loss of
assignents, because they do not save certain registers(cx,dx) -> see
"Exception semantics" at
Nevertheless possible future changes on make/get/setcontext will not be
able to affect Modula-3 when extracting the SP from the context record
any more if it does not rely on glibc functions.
Another solution is to link against the old glibc files (unpacked into

> ldd $(which m3build)
linux-gate.so.1 => (0xffffe000)
libm3front.so.1 =>
/usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000)
libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000)
libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000)
/lib/anc/9.3/ld-linux.so.2 (0xb7ef8000)

Please tell me if you are intereseted in any of both solutions.
I would suppose a solution for CM3 not to differ that much.

Elmar Stellnberger

Tony Hosking wrote:
> I have a question that may influence the direction we take with
> user-level threading support. Currently, user-level threading is
> broken on platforms that implement secure setjmp/longjmp via
> encryption since hacking the jump buffers the way we currently do for
> user-level threading triggers longjmp errors. A better alternative is
> to use makecontext/getcontext/setcontext on platforms that support it.
> For example, I know of the following situation for the targets I track:
> Target System (pthreads) threads User (setjmp/longjmp) threads User
> (getcontext/setcontext) threads
> LINUXLIBC6 YES NO unimplemented
> SOLgnu YES unimplemented YES (but not using makecontext)
> PPC_DARWIN YES NO no getcontext/setcontext
> I386_DARWIN YES NO no getcontext/setcontext
> FreeBSD NO YES unimplemented
> Ideally, we would implement all user-level threading using makecontext
> and friends, but my question is how many of our user-level threading
> targets actually support that API? One strategy would be to
> re-implement user-level threading using makecontext, etc., but fake up
> makecontext support, etc., on those targets that don't have it.
> I would hate to lose the user-level thread support just because it
> makes sense in some situations (e.g., embedded, uni-processor).

More information about the M3devel mailing list