<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Gill Sans";
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:GillSans-Light;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.ecxapple-style-span
{mso-style-name:ecxapple-style-span;}
span.ecxapple-converted-space
{mso-style-name:ecxapple-converted-space;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Jay:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">When you say native 32/64-bit “should be ok”, you really mean ok with respect to the SYSWOW64 problem you’ve identified.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Both of these native implementations still have threading misbehaviors as identified by the thread test program. Correct?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--Randy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> jayk123@hotmail.com [mailto:jayk123@hotmail.com]
<b>On Behalf Of </b>Jay K<br>
<b>Sent:</b> Thursday, January 23, 2014 2:57 PM<br>
<b>To:</b> Tony; Coleburn, Randy<br>
<b>Cc:</b> m3devel<br>
<b>Subject:</b> EXT:RE: [M3devel] EXT: proposal for getting wow64 context/stack reliably?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<span style="font-family:"Calibri","sans-serif"">There are no linker tricks. There are no syscalls, they aren't a special case just about anywhere, there are just functions, all treated the same.<br>
Correct it is only 32bit-on-64bit. Native 32bit should be ok. Native 64bit should be ok.<br>
<br>
- Jay<o:p></o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="margin-left:.5in;text-align:center">
<span style="font-family:"Calibri","sans-serif"">
<hr size="3" width="100%" align="center" id="stopSpelling">
</span></div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif"">From:
<a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>
Date: Thu, 23 Jan 2014 11:51:02 -0500<br>
To: <a href="mailto:rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a><br>
CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a>; <a href="mailto:jay.krell@cornell.edu">
jay.krell@cornell.edu</a><br>
Subject: Re: [M3devel] EXT: proposal for getting wow64 context/stack reliably?<br>
<br>
Yes, agreed.<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif"">We need to address the native thread problem on all platforms (both pthread and windows).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif"">However, this particular problem is pernicious if we need to save M3 stack state at all external calls.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif"">Are there any linker tricks for Windows one can use to wrap only system calls?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif"">I note that cooperative suspend will also need to do this at system calls so we can treat threads running code running outside of Modula-3 as essentially stopped,
This approach is used for all modern Java implementations that I am aware of.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif"">It really begins to sound like we must bite the bullet and move to cooperative threading so that we can guarantee GC safepoints where we can safely get the thread
state.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span class="ecxapple-style-span"><span style="font-size:9.0pt;font-family:"Gill Sans","serif";color:blue">Antony Hosking</span></span><span class="ecxapple-converted-space"><span style="font-size:9.0pt;font-family:"Gill Sans","serif";color:black"> </span></span><span class="ecxapple-style-span"><span style="font-size:9.0pt;font-family:"Gill Sans","serif";color:black">|</span></span><span class="ecxapple-converted-space"><span style="font-size:9.0pt;font-family:"Gill Sans","serif";color:black"> </span></span><span class="ecxapple-style-span"><span style="font-size:9.0pt;font-family:"Gill Sans","serif";color:black">Associate
Professor | Computer Science | Purdue University</span></span><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif";color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span class="ecxapple-style-span"><span style="font-size:9.0pt;font-family:"GillSans-Light","serif";color:black">305 N. University Street | West Lafayette | IN 47907 | USA</span></span><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif";color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span class="ecxapple-style-span"><span style="font-size:9.0pt;font-family:"Gill Sans","serif";color:blue">Mobile</span></span><span class="ecxapple-converted-space"><span style="font-size:9.0pt;font-family:"GillSans-Light","serif";color:black"> </span></span><span class="ecxapple-style-span"><span style="font-size:9.0pt;font-family:"GillSans-Light","serif";color:black">+1
765 427 5484</span></span><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif";color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif";color:black"><br>
<br>
<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""><br>
<br>
<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif"">On Jan 23, 2014, at 6:59 AM, Coleburn, Randy <<a href="mailto:rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Jay,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">If I'm following you correctly, you are saying that this bug happens when running on 64bit Windows, but not on 32bit, since it applies only to SysWOW64. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Since the thread test program also misbehaves on 32bit Windows, there must yet be some other bug in the underlying implementation affecting both
32 & 64 bit platforms. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Thus, the SysWOW64 issue is a 2nd, additional problem for 64bit. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Has anyone made any progress in solving the 1st, underlying problem affecting both 32/64 bit Windows?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">--Randy<br>
<br>
Sent from my iPhone<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
On Jan 23, 2014, at 2:58 AM, "Jay K" <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> There is a behavior/bug in wow64. <span class="ecxapple-converted-space"> </span><br>
Bing for "wow64 GetThreadContext" "wow64 stack pointer", etc.<br>
<br>
<br>
<br>
SuspendThread / GetThreadContext work like this: <span class="ecxapple-converted-space"> </span><br>
<br>
<br>
32bit processes consist almost entirely of 32bit code. <span class="ecxapple-converted-space"> </span><br>
There is a small amount of 64bit code. <span class="ecxapple-converted-space"> </span><br>
<br>
<br>
If you suspend while running 32bit code, GetThreadContext works. <span class="ecxapple-converted-space"> </span><br>
if you suspend while running 64bit code, GetThreadContext usually but not always works. <span class="ecxapple-converted-space"> </span><br>
<br>
<br>
64bit code is run en route to syscalls. <span class="ecxapple-converted-space"> </span><br>
For example you call: <span class="ecxapple-converted-space"> </span><br>
1 kernel32!Sleep <span class="ecxapple-converted-space"> </span><br>
2 it calls 32bit NtDelayExecution <span class="ecxapple-converted-space"> </span><br>
3 that calls wow64NtDelayExecutation (via a cross segment "far" jmp or call)<span class="ecxapple-converted-space"> </span><br>
4 which calls native NtDelayExecuation <span class="ecxapple-converted-space"> </span><br>
<br>
<br>
In between 2 and 3, within 64bit code, the 32bit context is saved. <span class="ecxapple-converted-space"> </span><br>
You can step through it very easily in a debugger. Really.<span class="ecxapple-converted-space"> </span><br>
Where GetThreadContext knows where to get it. <span class="ecxapple-converted-space"> </span><br>
The problem is that saving context is not atomic. <span class="ecxapple-converted-space"> </span><br>
You can suspend while saving context. <span class="ecxapple-converted-space"> </span><br>
<br>
<br>
What to do?<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
scratch/wow64stack contains a program that detects the bug.<br>
I believe it is the basis of a workaround for the bug. <span class="ecxapple-converted-space"> </span><br>
<br>
<br>
Proposal is that in the compiler, for I386_NT/NT386/I386_MINGWIN/I386_CYGWIN/I386_INTERIX platforms,<span class="ecxapple-converted-space"> </span><br>
not only functions that use exception handling, but also functions that call "extern" functions <span class="ecxapple-converted-space"> </span><br>
call GetActivation / SetActivation and therein save/set/restore the stack pointer. And garbage collection<br>
use that, if it isn't zero.<span class="ecxapple-converted-space"> </span><br>
Normally it will be zero. <span class="ecxapple-converted-space"> </span><br>
Syscalls do nest -- I can call SendMessage and in my window proc call CreateFile. <span class="ecxapple-converted-space"> </span><br>
That is why it isn't a set/set-zero pattern (like in the test program). <span class="ecxapple-converted-space"> </span><br>
<br>
<br>
Downside: We would like to get rid of GetActivation / SetActivation, i.e. and reuse efficient C++ exception handling.<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
Rejected counter proposal:<span class="ecxapple-converted-space"> </span><br>
Don't suspend/gc when running a syscall. <span class="ecxapple-converted-space"> </span><br>
No -- you can Sleep() a while. You can/should-be-able-to suspend and GC during that. <span class="ecxapple-converted-space"> </span><br>
<br>
<br>
Possible augmentation: if running native, short circuit most of this<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
Rejected counter proposal: Have I386_NT_NATIVE that doesn't do this stuff. Relegate<span class="ecxapple-converted-space"> </span><br>
compatibility to I386_NT_COMPATIBLE. I don't like having more platforms/targets.<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
AMD64_NT wouldn't have this stuff. Nor would other hypothetical platforms like ARM32_NT,<span class="ecxapple-converted-space"> </span><br>
until/unless there is another 32bit platform runable on some similar 64bit platforms.<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
Performance impact: hypothetically large but probably not noticable.<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
Furthe refinements: It isn't extern/native code per se, it is syscalls.<br>
We could further augment pragmas to discern them.<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
We could leave it to writing "syscall wrappers" and informally (no enforcement) ban direct calls<span class="ecxapple-converted-space"> </span><br>
to any functions that make syscalls. This is likely too hard to maintain and too unfriendly.<span class="ecxapple-converted-space"> </span><br>
It pretty viable in m3core, but then also libm3 and Trestle and Qt wrappers, etc...<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
<br>
Agreed? I'll make the compiler change?<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
Oh, also, not just stack pointer, but other registers, at least non-volatiles?<br>
<br>
<br>
Eventually cooperative suspend will cause this to fall away as a problem..<br>
<br>
<br>
- Jay<o:p></o:p></span></p>
</div>
</blockquote>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>