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

[Nicolas Cellier]

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?

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/aefdfef2/attachment.html>