[Vm-dev] 64bits Pharo VM for windows

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 21 00:56:33 UTC 2017


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.



>
>
> 2017-03-19 21:03 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>> And currently https://github.com/OpenSmalltalk/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 gmai
>> l.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170320/47405782/attachment.html>


More information about the Vm-dev mailing list