Hi Eliot, I'll try the assert if I can find a time slot today, otherwise this evening. I could also have printed the jump_buf address in gdb, but it was too late yesterday ;)
2017-03-21 2:19 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
On Mon, Mar 20, 2017 at 6:01 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Nicolas,
On Mon, Mar 20, 2017 at 5:56 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Nicolas,
On Mon, Mar 20, 2017 at 3:45 PM, Nicolas Cellier < nicolas.cellier.aka.nice@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.
Hmmm. I expect we need code in the ceReturnToInterpreterTrampoline that establishes the stack alignment requirement. ceReturnToInterpreter: would be called from machine code where there is only 8 byte alignment on x64 (& 4 byte alignment on 32-bit VMs). If you like I can try and implement this tomorrow.
Looking at the code, that's not necessary. The trampoline still switches to the C stack, which should be correctly aligned. So yes, definitely add the "self assertCStackWellAligned" to both ceReturnToInterpreter: and ceBaseFrameReturn:. It looks like the issue is whether the returnToInterpreter jmpbuf is correctly aligned.
2017-03-19 21:03 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai
l.com>:
And currently https://github.com/OpenSmallta lk/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@gmail.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@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@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@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
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot