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

[Nicolas Cellier]

2017-05-18 0:13 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

>
>
> 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...
>

And with the __builtin_sjlj hardocded directly in cointerp.c the execution
goes a bit further

Program received signal SIGSEGV, Segmentation fault.
0x00000000000008d4 in ?? ()
(gdb) bt
#0  0x00000000000008d4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) call printCallStack()

          0xefaf40 M FilePath class(Behavior)>new 0x4511150: a(n) FilePath
class
          0xefaf70 M FilePath class>pathName:isEncoded: 0x4511150: a(n)
FilePath class
          0xefafc0 I FilePath class>pathName: 0x4511150: a(n) FilePath class
          0xefb010 I FileDirectory class>setDefaultDirectory: 0x44faaa0:
a(n) FileDirectory class
          0xefb058 I FileDirectory class>startUp 0x44faaa0: a(n)
FileDirectory class
          0xefb088 M FileDirectory class(Behavior)>startUp: 0x44faaa0: a(n)
FileDirectory class
          0xefb0e0 M [] in SmalltalkImage>send:toClassesNamedIn:with:
0x4553ae0: a(n) SmalltalkImage
          0xefb130 I OrderedCollection>do: 0x48a3808: a(n) OrderedCollection
          0xefb180 I SmalltalkImage>send:toClassesNamedIn:with: 0x4553ae0:
a(n) SmalltalkImage
          0xefb1d8 I SmalltalkImage>processStartUpList: 0x4553ae0: a(n)
SmalltalkImage
          0xefb230 I SmalltalkImage>snapshot:andQuit:withExitCode:embedded:
0x4553ae0: a(n) SmalltalkImage
         0x69349f0 s SmalltalkImage>snapshot:andQuit:embedded:
         0x6943690 s SmalltalkImage>snapshot:andQuit:
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170518/a24b5f66/attachment-0001.html>