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

[Tony Hosking]

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 University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +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.
> 
>  - Jay
> From: 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 University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +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/20140124/df5802c0/attachment-0002.html>