[M3devel] proposal for getting wow64 context/stack reliably?

[Jay K]

I might yet have another solution here..there might be a way to detect the race and retry...later..

 - Jay

From: hosking at cs.purdue.edu
Date: Fri, 24 Jan 2014 13:24:35 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] proposal for getting wow64 context/stack reliably?

As a way forward I propose that we indeed treat EXTERNAL calls as needing to capture a GC context.  At least that should be the default.Some calls could be annotated as not needing to capture the GC context with a different EXTERNAL pragma.  Knowing that such a call can safely ignore saving the context would require inspection of the external function, or understanding of its behavior.

Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484


On Jan 23, 2014, at 6:09 PM, Jay K <jay.krell at cornell.edu> wrote:Yes. Agreed.
They should be ok with respect to SuspendThread + GetThreadContext. The small C++ test program in scratch.
I don't know about the "other" problem that affects even pthreads and I agree we should focus on that first, on pthreads, native I386_NT, and possibly AMD64_NT, but for now, at least briefly, ignore I386_NT on 64bit Windows.
 
 
 - Jay

 
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Thu, 23 Jan 2014 22:23:43 +0000
Subject: Re: [M3devel] proposal for getting wow64 context/stack reliably?

Jay: When you say native 32/64-bit “should be ok”, you really mean ok with respect to the SYSWOW64 problem you’ve identified.  Both of these native implementations still have threading misbehaviors as identified by the thread test program.  Correct? --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, January 23, 2014 2:57 PM
To: Tony; Coleburn, Randy
Cc: m3devel
Subject: EXT:RE: [M3devel] EXT: proposal for getting wow64 context/stack reliably? 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.
Correct it is only 32bit-on-64bit. Native 32bit should be ok. Native 64bit should be ok.

 - JayFrom: hosking at cs.purdue.edu
Date: Thu, 23 Jan 2014 11:51:02 -0500
To: rcolebur at SCIRES.COM
CC: m3devel at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] EXT: proposal for getting wow64 context/stack reliably?

Yes, agreed.We need to address the native thread problem on all platforms (both pthread and windows). However, this particular problem is pernicious if we need to save M3 stack state at all external calls. Are there any linker tricks for Windows one can use to wrap only system calls? 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. 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. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 



 On Jan 23, 2014, at 6:59 AM, Coleburn, Randy <rcolebur at SCIRES.COM> wrote: Jay, 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.  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.  Thus, the SysWOW64 issue is a 2nd, additional problem for 64bit.  Has anyone made any progress in solving the 1st, underlying problem affecting both 32/64 bit Windows? --Randy

Sent from my iPhone
On Jan 23, 2014, at 2:58 AM, "Jay K" <jay.krell at cornell.edu> wrote:  There is a behavior/bug in wow64.  
  Bing for "wow64 GetThreadContext" "wow64 stack pointer", etc.



  SuspendThread / GetThreadContext work like this:  


  32bit processes consist almost entirely of 32bit code.  
  There is a small amount of 64bit code.  


  If you suspend while running 32bit code, GetThreadContext works.  
  if you suspend while running 64bit code, GetThreadContext usually but not always works.  


  64bit code is run en route to syscalls.  
  For example you call:  
    1 kernel32!Sleep   
    2 it calls 32bit NtDelayExecution   
    3 that calls wow64NtDelayExecutation  (via a cross segment "far" jmp or call) 
    4 which calls native NtDelayExecuation   

 
  In between 2 and 3, within 64bit code, the 32bit context is saved.  
    You can step through it very easily in a debugger. Really. 
  Where GetThreadContext knows where to get it.  
  The problem is that saving context is not atomic.  
  You can suspend while saving context.  


  What to do? 


  scratch/wow64stack contains a program that detects the bug.
  I believe it is the basis of a workaround for the bug.   


  Proposal is that in the compiler, for I386_NT/NT386/I386_MINGWIN/I386_CYGWIN/I386_INTERIX platforms, 
  not only functions that use exception handling, but also functions that call "extern" functions  
  call GetActivation / SetActivation and therein save/set/restore the stack pointer. And garbage collection
  use that, if it isn't zero. 
  Normally it will be zero.  
  Syscalls do nest -- I can call SendMessage and in my window proc call CreateFile.  
  That is why it isn't a set/set-zero pattern (like in the test program).   


  Downside: We would like to get rid of GetActivation / SetActivation, i.e. and reuse efficient C++ exception handling. 


  Rejected counter proposal: 
   Don't suspend/gc when running a syscall.  
   No -- you can Sleep() a while. You can/should-be-able-to suspend and GC during that.  


 Possible augmentation: if running native, short circuit most of this 


  Rejected counter proposal: Have I386_NT_NATIVE that doesn't do this stuff. Relegate 
   compatibility to I386_NT_COMPATIBLE. I don't like having more platforms/targets. 


   AMD64_NT wouldn't have this stuff. Nor would other hypothetical platforms like ARM32_NT, 
   until/unless there is another 32bit platform runable on some similar 64bit platforms. 


  Performance impact: hypothetically large but probably not noticable. 


  Furthe refinements: It isn't extern/native code per se, it is syscalls.
  We could further augment pragmas to discern them. 


  We could leave it to writing "syscall wrappers" and informally (no enforcement) ban direct calls 
  to any functions that make syscalls. This is likely too hard to maintain and too unfriendly. 
  It pretty viable in m3core, but then also libm3 and Trestle and Qt wrappers, etc... 



  Agreed? I'll make the compiler change? 


Oh, also, not just stack pointer, but other registers, at least non-volatiles?


Eventually cooperative suspend will cause this to fall away as a problem..


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140125/b19a595a/attachment-0002.html>