<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Nicolas,<br></div><div><br>On May 17, 2017, at 3:13 PM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-05-16 17:00 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Hi Nicolas,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 16, 2017 at 7:10 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmai<wbr>l.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-05-15 17:39 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Hi Nicolas,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 7:37 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmai<wbr>l.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><div><div><div><div><div>Hi Eliot,<br></div>I've not worked on it for a month or so, but last time I tried, the VM failed during image startup.<br></div>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,<br></div>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.<br></div>I'll try to report ASAP.<br><br></div>There's a first thing needed before testing it:<br>either add some -DWIN64ABI compilation flag somewhere, or add these 3 lines in cogit.c preamble<br><br>#if WIN64 <br># define WIN64ABI 1<br>#endif<br></div></blockquote><div><br></div><div>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.</div><div> </div></div></div></div></blockquote><div><div>Yes thanks, if it can work automagically then it's better.<br></div><div>About Win64 status, maybe you remember the thread opened on vm-dev in March 2017, where I mentionned the error:<br></div></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Ben, what have you discovered about unwinding the stack during longjmp on win64?</div><br></div></div></div></blockquote><div><br></div><div>Hmm, if I stepi/nexti into longjmp then I have things like this:<br><br>(gdb)<br>0x0000000077c07c34 in ntdll!RtlUnwindEx () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll<br>(gdb)<br>0x0000000077c07c37 in ntdll!RtlUnwindEx () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll<br>(gdb)<br>0x0000000077c07c39 in ntdll!RtlUnwindEx () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll<br>(gdb)<br>0x0000000077c07c3c in ntdll!RtlUnwindEx () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll<br>(gdb)<br>0x0000000077c57eac in ntdll!TpAlpcRegisterCompletionList () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll<br>(gdb)<br>0x0000000077c57eb1 in ntdll!TpAlpcRegisterCompletionList () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll<br>(gdb)<br>gdb: unknown target exception 0xc0000028 at 0x77cb8078<br><br>Program received signal ?, Unknown signal.<br>0x0000000077cb8078 in ntdll!RtlRaiseStatus () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll<br>(gdb)<br><br><br></div><div>Is it what you don't want to see?<br></div></div></div></div></div></blockquote><div><br></div>Right. No unwinding is necessary since the vm is merely reentering the interpreter at the same stack level from which it entered machine code.<div><br></div><div>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.<br><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I found this:<br><a href="http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/longjmp/2016/02/29/go-windows-setjmp-x86.html">http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/longjmp/2016/02/29/go-windows-setjmp-x86.html</a><br><a href="https://sourceforge.net/p/mingw-w64/bugs/465/">https://sourceforge.net/p/mingw-w64/bugs/465/</a><br><br></div><div>I will try the builtin... <br></div></div></div></div>
</div></blockquote></div></div></body></html>