[Vm-dev] 64bits Pharo VM for windows

Tue Mar 21 23:47:12 UTC 2017

Gah, stupid me, I didn't realized that the vm was compiled for SysV...
I need to define -DWIN64ABI somewhere...

2017-03-21 22:18 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

>
>
> 2017-03-21 7:48 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>> Hi Eliot,
>> I'll try the assert if I can find a time slot today, otherwise this
>> evening.
>> I could also have printed the jump_buf address in gdb, but it was too
>> late yesterday ;)
>>
>>
>> 2017-03-21 2:19 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>>
>>>
>>>
>>> On Mon, Mar 20, 2017 at 6:01 PM, Eliot Miranda <eliot.miranda at gmail.com>
>>> wrote:
>>>
>>>> Hi Nicolas,
>>>>
>>>> On Mon, Mar 20, 2017 at 5:56 PM, Eliot Miranda <eliot.miranda at gmail.com
>>>> > wrote:
>>>>
>>>>> Hi Nicolas,
>>>>>
>>>>> On Mon, Mar 20, 2017 at 3:45 PM, Nicolas Cellier <
>>>>> nicolas.cellier.aka.nice at 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.
>>>>>
>>>>
>>>> Hmmm.  I expect we need code in the ceReturnToInterpreterTrampoline
>>>> that establishes the stack alignment requirement.  ceReturnToInterpreter:
>>>> would be called from machine code where there is only 8 byte alignment on
>>>> x64 (& 4 byte alignment on 32-bit VMs).  If you like I can try and
>>>> implement this tomorrow.
>>>>
>>>
>>>  Looking at the code, that's not necessary.  The trampoline still
>>> switches to the C stack, which should be correctly aligned.  So yes,
>>> definitely add the "self assertCStackWellAligned" to both
>>> ceReturnToInterpreter: and ceBaseFrameReturn:.  It looks like the issue is
>>> whether the returnToInterpreter jmpbuf is correctly aligned.
>>>
>>>
>
> The STACK_ALIGN_BYTES is 16 in good agreement with WIN64 ABI and
> assertCStackWellAligned() do succeed in ceReturnToInterpreter...
>
> So, I added the assertion on setjmp and longjmp, but they do not fail.
> The jmp_buf reenterInterpreter is correctly aligned on 16 bytes boundary.
> There is a declaration like this in setjmp.h
>  typedef _CRT_ALIGN(16) struct _SETJMP_FLOAT128
> So local and global jmp_buf variables are allways well aligned by the C
> compiler(s)
>
> The jpeg problem was caused by putting the jmp_buf into a structure.
> Apparently, gcc and clang fail to correctly handle that case
> (they should first align the whole struct on 16 bytes then align the
> offset of the jmp_buf member).
>
> There are other cases that will be problematic in Win64 exactly like the
> jpeg case, for example I see:
> siglongjmp((vmCallbackContext->trampoline)... in
> returnAsThroughCallbackContext
> longjmp(GIV(jmpBuf)[GIV(jmpDepth)]...in callbackLeave (only #if
> SQ_USE_GLOBAL_STRUCT)
>
> We should memcpy these to a local jmp_buf for WIN64 compatibility.
>
> But the VM failed before ever reaching one of these callbacks (we should
> have none in Squeak by default)
>
> So, wrong guess from my side for the moment, seeing longjmp on the call
> stack raised that false alarm.
>
>
>
>>
>>>> 2017-03-19 21:03 GMT+01:00 Nicolas Cellier <
>>>>>> nicolas.cellier.aka.nice at gmail.com>:
>>>>>>
>>>>>>> And currently https://github.com/OpenSmallta
>>>>>>> lk/opensmalltalk-vm/blob/Cog/spur64src/vm/cogitX64.c is generated
>>>>>>> for SysV only.
>>>>>>> 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 at 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 at 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 at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And the appveyor builds are green
>>>>>>>>>> https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.579
>>>>>>>>>>
>>>>>>>>>> 2017-03-19 17:31 GMT+01:00 Nicolas Cellier <
>>>>>>>>>> nicolas.cellier.aka.nice at 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> _,,,^..^,,,_
>>>> best, Eliot
>>>>
>>>
>>>
>>>
>>> --
>>> _,,,^..^,,,_
>>> best, Eliot
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170322/ecf6f6bd/attachment-0001.html>