Exception handling segfaults in the msys2/mingw64 build on Windows about pure-lang

[agraef]

This was previously reported by Jiri Spitz as BB Issue #10, and there's a related mailing list thread from 2013.

As suggested by Jiri, about the simplest way to reproduce the issue is to run this in the interpreter:

[1,2]!5;

[agraef]

Just for the record, the root cause seems to be that mingw64 uses SJLJ itself in order to implement C++ exceptions, which of course gets in the way of Pure's own use of SJLJ. This is discussed at length in the aforementioned ticket and ml conversation.

[agraef]

Looks like using __builtin_setjmp and __builtin_longjmp instead of the msvc versions of setjmp/longjmp should fix this, cf. http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/longjmp/2016/02/29/go-windows-setjmp-x86.html. Currently giving this a try.

[agraef]

Fixed in rev. 088b875.

[agraef]

Still segfaults (at random) when running pure test011.pure from bash. Unfortunately, the gdb backtrace isn't particularly helpful:

(gdb) bt
#0  0x00007ff8db824faf in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\Windows\SYSTEM32\ntdll.dll
#1  0x00007ff8db7e6d07 in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x00007ff8db823ebd in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\Windows\SYSTEM32\ntdll.dll
#3  0x00007ff8db7d53ac in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll
#4  0x00007ff8db746a99 in ntdll!RtlFreeHeap ()
   from C:\Windows\SYSTEM32\ntdll.dll
#5  0x00007ff8db4e984c in msvcrt!free () from C:\Windows\System32\msvcrt.dll
#6  0x000000000015ce57 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)