[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] try appveyor (bed86c5)

[Nicolas Cellier]

2017-05-18 1:03 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
> Hi Nicolas,
>
> On May 17, 2017, at 3:13 PM, Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com> wrote:
>
>
>
> 2017-05-16 17:00 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>>
>> Hi Nicolas,
>>
>> On Tue, May 16, 2017 at 7:10 AM, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> 2017-05-15 17:39 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>>
>>>>
>>>> Hi Nicolas,
>>>>
>>>> On Mon, May 15, 2017 at 7:37 AM, Nicolas Cellier <
>>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>
>>>>>
>>>>> Hi Eliot,
>>>>> I've not worked on it for a month or so, but last time I tried, the VM
>>>>> failed during image startup.
>>>>> AFAIR, it had time to produce and execute some JIT, but I can't say
>>>>> more until I have access to my laptop this evening,
>>>>> I've tried some crazy things like tracing every VM function thru gdb
>>>>> hack, unfortunately, it does not scale (slow) and also perturbates the VM.
>>>>> I'll try to report ASAP.
>>>>>
>>>>> There's a first thing needed before testing it:
>>>>> either add some -DWIN64ABI compilation flag somewhere, or add these 3
>>>>> lines in cogit.c preamble
>>>>>
>>>>> #if WIN64
>>>>> # define WIN64ABI 1
>>>>> #endif
>>>>>
>>>>
>>>> I was thinking it would be natural to add it to the build.win64x64
>>>> makefiles.  But I've hacked something up to add the above to cogit.c.
>>>>
>>>>
>>> Yes thanks, if it can work automagically then it's better.
>>> About Win64 status, maybe you remember the thread opened on vm-dev in
>>> March 2017, where I mentionned the error:
>>>
>>
>> Ah, right.  I've reread the thread.  Thank you.  So given that the
>> alignment assert never fails the next likely suspect is unwinding the stack
>> on longjmp.  Since we would like to avoid the cost of unwinding the stack,
>> and because we know there is nothing to run as we unwind the stack we
>> should see if there is a form of longjmp that does not try to unwind the
>> stack.  Alternatively we might have to implement our own longjmp in JIT
>> code for this specific purpose.
>>
>> Ben, what have you discovered about unwinding the stack during longjmp on
>> win64?
>>
>>
> Hmm, if I stepi/nexti into longjmp then I have things like this:
>
> (gdb)
> 0x0000000077c07c34 in ntdll!RtlUnwindEx () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> (gdb)
> 0x0000000077c07c37 in ntdll!RtlUnwindEx () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> (gdb)
> 0x0000000077c07c39 in ntdll!RtlUnwindEx () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> (gdb)
> 0x0000000077c07c3c in ntdll!RtlUnwindEx () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> (gdb)
> 0x0000000077c57eac in ntdll!TpAlpcRegisterCompletionList () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> (gdb)
> 0x0000000077c57eb1 in ntdll!TpAlpcRegisterCompletionList () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> (gdb)
> gdb: unknown target exception 0xc0000028 at 0x77cb8078
>
> Program received signal ?, Unknown signal.
> 0x0000000077cb8078 in ntdll!RtlRaiseStatus () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> (gdb)
>
>
> Is it what you don't want to see?
>
>
> Right.  No unwinding is necessary since the vm is merely reentering the
> interpreter at the same stack level from which it entered machine code.
>
> So the thing to try and find is a setjmp/longjmp implementation that does
> not attempt to unwind the stack and to use it for the renter interpreter
> and return to callback longjmps.
>
>
So in mingw-w64, unless USE_NO_MINGW_SETJMP_TWO_ARGS has been defined (it
is not by any default include file)
there is a possibility to pass a 2nd parameter to a _setjmp, and if this
2nd argument is NULL, there will be no context unwinding.

http://mingw-w64-public.narkive.com/1mUoWEfG/setjmp-longjmp-crashes-second-setjmp-argument
https://patchwork.ozlabs.org/patch/437794/
grep -r USE_NO_MINGW_SETJMP_TWO_ARGS
/usr/x86_64-w64-mingw32/sys-root/mingw/include

Consequently, we need to amend sigsetjmp macros for WIN64 in cointerp.c
header:
something like:

#undef sigsetjmp
#undef siglongjmp
#if _WIN64
# define sigsetjmp(jb,ssmf) _setjmp(jb,NULL)
# define siglongjmp(jb,v) longjmp(jb,v)
#elif _WIN32
# define sigsetjmp(jb,ssmf) setjmp(jb)
# define siglongjmp(jb,v) longjmp(jb,v)
...

It's less intrusive than __builtin_setjmp _builtin_longjmp (because the
last one only work for a literal return value).

After applying this patch, the startup list processes a bit further but
then crashes with a SEGV, so there is yet another problem to be inquired...


> I found this:
> http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/
> longjmp/2016/02/29/go-windows-setjmp-x86.html
> https://sourceforge.net/p/mingw-w64/bugs/465/
>
> I will try the builtin...
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170518/337ff1bb/attachment-0001.html>