Hi Nicolas,

On Mon, Mar 20, 2017 at 3:45 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
 
Thanks Eliot for pushing WIN64 ABI further!

So the failure is this one:

gdb: unknown target exception 0xc0000028 at 0x774c8078

Program received signal ?, Unknown signal.
0x00000000774c8078 in ntdll!RtlRaiseStatus () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) where
#0  0x00000000774c8078 in ntdll!RtlRaiseStatus () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x0000000077467eb6 in ntdll!TpAlpcRegisterCompletionList () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#2  0x000007fefe08e5a3 in msvcrt!longjmp () from /cygdrive/c/Windows/system32/msvcrt.dll
#3  0x0000000000419502 in ceReturnToInterpreter (anOop=176164968) at ../../spur64src/vm/gcc3x-cointerp.c:16504
#4  0x000000000a801086 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I now suspect the jmp_buf alignment problem that I had to workaround in jpeg plugin:
It must be aligned on 16 bytes boundary in Win64, but sometimes the compiler fails to honour this requirement
See https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/120

Hmph.  So the stack /should/ be aligned on a 16-byte boundary and hence the compiler /should/ be able to maintain the invariant (see platforms/Cross/vm/sqCogStackAlignment.h; in fact on Mac OS X the alignment is 32 bytes).
 
Let me suggest that you add the following to the preamble:

#if WIN64
# define sigsetjmp(jb,ssmf) (assert(((int)jb & 15) == 0, setjmp(jb))
# define siglongjmp(jb,v) (assert(((int)jb & 15) == 0, longjmp(jb,v))
#elif WIN32
...

and make sure there's a self assertCStackWellAligned send in ceReturnToInterpreter.





2017-03-19 21:03 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
It's necessary to hack the CogX64Compiler SysV class var initialization and generate a win64 specific cogitX64.c.


2017-03-19 20:34 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Hi Clement,
it's been a while since I last tested, but in a few words:
- win64 use it's own ABI
- we have to assign the registers differently than sysV
- the experiments I did resulted in VM crashing early (before opening window)

Nicolas

2017-03-19 20:29 GMT+01:00 Clément Bera <bera.clement@gmail.com>:
 
Thank you very much for doing Nicolas. It is very important for many Pharo users to use Pharo 64 bits on Windows.

What are the problems you have when trying to build the VM with the JIT that you don't have when building the stack VM ? Is it about API to make the memory executable, is it about calling conventions ?

On Sun, Mar 19, 2017 at 12:14 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
 

2017-03-19 17:31 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Hi,
I've built a 64bits pharo.stack.spur VM for windows on my machine,
and I'm uploading the changes to opensmalltalk-vm in branch
build_pharo_win32_with_cygwin

If the appveyor job correctly succeed, I will emit a pull request.

The VM does not have the SqueakSSL plugin yet.

The 64bits squeak/pharo.cog.spur JIT for windows is still to come,
but I did not work on it for a few months...
One thing at a time.

Let's cross finger

Nicolas











--
_,,,^..^,,,_
best, Eliot