[Vm-dev] 64bits Pharo VM for windows

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Mar 21 06:48:10 UTC 2017


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.
>
>
>> 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/20170321/cba16c8b/attachment-0001.html>


More information about the Vm-dev mailing list