<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=US-ASCII" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
It seems to be the same message, which I have sent to you.<br>
Has there been anything new you wanted to tell me?<br>
Is the setjmp/longjmp replacement of interest?<br>
<br>
Elmar Stellnberger wrote:
<blockquote cite="mid:468BE2F4.7010805@aon.at" type="cite">
<pre wrap=""> 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
<a class="moz-txt-link-freetext" href="http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html">http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html</a>.
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
/lib/anc):
</pre>
<blockquote type="cite">
<pre wrap="">ldd $(which m3build)
</pre>
</blockquote>
<pre wrap=""><!---->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.
Yours,
Elmar Stellnberger
Tony Hosking wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>