[Vm-dev] 64bits Pharo VM for windows

Tue Mar 21 01:19:50 UTC 2017

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.

> 2017-03-19 21:03 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>>> l.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/20170320/c9fe54bb/attachment.html>