<div dir="ltr"><div><div><div>Thanks Ronie and Esteban.<br>This seems to be an alignment problem indeed.<br></div>What I see is that alignment is defined at least in 3 different places:<br></div>- platforms/Cross/vm/sqCogStackAlignment.h<br>- platforms/Cross/plugins/IA32ABI/ia32abicc.c<br>- src/plugins/SqueakFFIPrims/IA32FFIPlugin.c and friends...<br>That's just too many different opinions!!! We have to unify that rather than adding a 4th opinion in a Makefile.<br><br></div><div>However, about ALLOCA_LIES_SO_USE_GETSP, I'm not so sure that "It is NOT the case of mingw."<br>Last time I used gdb, it WAS still the case, alloca was STILL lying.<br>See <a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2016-August/022985.html">http://lists.squeakfoundation.org/pipermail/vm-dev/2016-August/022985.html</a><br><br></div><div>BUT:<br>-----<br>forcing 16 bytes alignment supersedes the alloca hack, making it not strictly necessary anymore<br>see below in generated src/plgins/IA32FFIPlugin.c:<br><br> allocation = alloca(((stackSize + ((calloutState->structReturnSize)))) + (cStackAlignment()));<br> if (allocaLiesSoUseGetsp()) {<br> allocation = getsp();<br> }<br> if ((cStackAlignment()) != 0) {<br> allocation = ((char *) ((((((usqInt)allocation)) | ((cStackAlignment()) - 1)) - ((cStackAlignment()) - 1))));<br> }<br> (calloutState->argVector = allocation);<br><br>but we further do:<br><br> if ((0 + (cStackAlignment())) > 0) {<br> setsp((calloutState->argVector));<br> }<br><br></div><div>So if ever the stack pointer is greater than alloca return value, but we removed the ALLOCA_LIES hack,<br>the stack pointer is then set back to alloca returned value, avoiding the stack pointer offset problem</div><div>It would be worth writing a unit test case, and inquiring the reason why it lies in gcc mailing list to be sure...<br></div><div><br></div><div><div><div>cheers<br><div><div class="gmail_extra"><br><div class="gmail_quote">2016-11-29 18:14 GMT+01:00 Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@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>hah! <div>you know what is the sad part of this? I wrote that message… it was for the future me, but I forget to check our flags :P</div><div>I lost 2.5 days then + 2 days now. </div><div><br></div><div>this fixes the problem with Windows crashes (yay!) but not the problem with callbacks (booo!)… any idea in that area?</div><div><br></div><div>cheers, </div><div>Esteban</div><div><br><div><blockquote type="cite"><div>On 29 Nov 2016, at 17:30, Ronie Salgado <<a href="mailto:roniesalg@gmail.com" target="_blank">roniesalg@gmail.com</a>> wrote:</div><br class="gmail-m_-6181798751789921155gmail-m_4008827957260114081m_8444459666016971431Apple-interchange-newline"><div><div dir="ltr">The last week I was having this exactly same crash in the MinimalisticHeadless branch, with both MinGW and with Visual Studio. I managed to get the VM working with MinGW (not yet with MSVC) by using the following defines,which I copied from the old Pharo CMake scripts:<br><br> -DSTACK_ALIGN_BYTES=16
-DALLOCA_LIES_SO_USE_GETSP=0<br><br>In the pharo-vm, the CogFamilyWindowsConfig >> #commonCompilerFlags method starts with the following comment:<br>commonCompilerFlags<br> "omit -ggdb2 to prevent generating debug info"<br> "Some flags explanation: <br> <br> STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too).<br> DALLOCA_LIES_SO_USE_GETSP=0 Some compilers return the stack address+4 on alloca function, <br> then FFI module needs to adjust that. It is NOT the case of mingw.<br> For more information see this thread: <a href="http://forum.world.st/There-are-something-fishy-with-FFI-plugin-td4584226.html" target="_blank">http://forum.world.st/There-ar<wbr>e-something-fishy-with-FFI-plu<wbr>gin-td4584226.html</a><br> "<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-11-29 9:32 GMT-03:00 Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@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><br><div><blockquote type="cite"><div>On 29 Nov 2016, at 13:04, Clément Bera <<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>> wrote:</div><br class="gmail-m_-6181798751789921155gmail-m_4008827957260114081m_8444459666016971431m_521498899662060592Apple-interchange-newline"><div><div dir="ltr">Hi,<div><br></div><div>Can you confirm this bug happen only in Windows ?</div></div></div></blockquote><div><br></div>yes, the crash is just in windows.<div>the callback problem is general (note that FFICallbackTests works fine, but I think this is related to the fact that it never enters the 2nd condition with the qsort function) .</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Do you have version number (both VMMaker and git commit) of the last version you have that was working ?</div></div></div></blockquote><div><br></div><div>sadly, not… I tried to get the latest working version, but with the mess I have to get the VM to build with opensmalltalk-vm, I couldn’t track it. </div><div>I suspect is related to the work on 64bits for windows, but I have no proof of that :P</div><div><br></div><div>Esteban</div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Thanks.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 29, 2016 at 11:54 AM, Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.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>
Hi,<br>
<br>
So, I’m building the PharoVM along with all his dependencies. For me, this is a major step because I can drop the old build process finally.<br>
Now, I’m having serious problems with FFI (that they were not present before), :<br>
<br>
<br>
1. CRASH IN WINDOWS (32bits):<br>
<br>
In Win32, it crashes automatically when trying to access this funtion:<br>
<br>
getEnvSize: nameString<br>
^ self ffiCall: #( int GetEnvironmentVariableA ( String nameString, nil, 0 ) ) module: #Kernel32<br>
<br>
(this works perfectly fine in older versions)<br>
<br>
2. CALLBACKS FAILING:<br>
<br>
Callbacks have problems. The examples passes but they are very simple… as soon as I try to do something complicates (like unqlite bindings or libgit2 bindings, who use callbacks intensively), callbacks stops working.<br>
I traced the problem up to this method:<br>
<br>
StackInterpreter>>#returnAs:Th<wbr>roughCallback:Context:<br>
<br>
returnAs: returnTypeOop ThroughCallback: vmCallbackContext Context: callbackMethodContext<br>
"callbackMethodContext is an activation of invokeCallback:[stack:register<wbr>s:jmpbuf:].<br>
Its sender is the VM's state prior to the callback. Reestablish that state (via longjmp),<br>
and mark callbackMethodContext as dead."<br>
<export: true><br>
<var: #vmCallbackContext type: #'VMCallbackContext *'><br>
| calloutMethodContext theFP thePage |<br>
<var: #theFP type: #'char *'><br>
<var: #thePage type: #'StackPage *'><br>
((self isIntegerObject: returnTypeOop)<br>
and: [self isLiveContext: callbackMethodContext]) ifFalse:<br>
[^false].<br>
calloutMethodContext := self externalInstVar: SenderIndex ofContext: callbackMethodContext.<br>
(self isLiveContext: calloutMethodContext) ifFalse:<br>
[^false].<br>
"We're about to leave this stack page; must save the current frame's instructionPointer."<br>
self push: instructionPointer.<br>
self externalWriteBackHeadFramePoin<wbr>ters.<br>
"Mark callbackMethodContext as dead; the common case is that it is the current frame.<br>
We go the extra mile for the debugger."<br>
(self isSingleContext: callbackMethodContext)<br>
ifTrue: [self markContextAsDead: callbackMethodContext]<br>
ifFalse:<br>
[theFP := self frameOfMarriedContext: callbackMethodContext.<br>
framePointer = theFP "common case"<br>
ifTrue:<br>
[(self isBaseFrame: theFP)<br>
ifTrue: [stackPages freeStackPage: stackPage]<br>
ifFalse: "calloutMethodContext is immediately below on the same page. Make it current."<br>
[instructionPointer := (self frameCallerSavedIP: framePointer) asUnsignedInteger.<br>
stackPointer := framePointer + (self frameStackedReceiverOffset: framePointer) + objectMemory wordSize.<br>
framePointer := self frameCallerFP: framePointer.<br>
self setMethod: (self frameMethodObject: framePointer).<br>
self restoreCStackStateForCallbackC<wbr>ontext: vmCallbackContext.<br>
"N.B. siglongjmp is defines as _longjmp on non-win32 platforms.<br>
This matches the use of _setjmp in ia32abicc.c."<br>
self siglong: vmCallbackContext trampoline jmp: (self integerValueOf: returnTypeOop).<br>
^true]]<br>
ifFalse:<br>
[self externalDivorceFrame: theFP andContext: callbackMethodContext.<br>
self markContextAsDead: callbackMethodContext]].<br>
"Make the calloutMethodContext the active frame. The case where calloutMethodContext<br>
is immediately below callbackMethodContext on the same page is handled above."<br>
(self isStillMarriedContext: calloutMethodContext)<br>
ifTrue:<br>
[theFP := self frameOfMarriedContext: calloutMethodContext.<br>
thePage := stackPages stackPageFor: theFP.<br>
"findSPOf:on: points to the word beneath the instructionPointer, but<br>
there is no instructionPointer on the top frame of the current page."<br>
self assert: thePage ~= stackPage.<br>
stackPointer := (self findSPOf: theFP on: thePage) - objectMemory wordSize.<br>
framePointer := theFP]<br>
ifFalse:<br>
[thePage := self makeBaseFrameFor: calloutMethodContext.<br>
framePointer := thePage headFP.<br>
stackPointer := thePage headSP].<br>
instructionPointer := self popStack.<br>
self setMethod: (objectMemory fetchPointer: MethodIndex ofObject: calloutMethodContext).<br>
self setStackPageAndLimit: thePage.<br>
self restoreCStackStateForCallbackC<wbr>ontext: vmCallbackContext.<br>
"N.B. siglongjmp is defines as _longjmp on non-win32 platforms.<br>
This matches the use of _setjmp in ia32abicc.c."<br>
self siglong: vmCallbackContext trampoline jmp: (self integerValueOf: returnTypeOop).<br>
"NOTREACHED"<br>
^true<br>
<br>
with the first siglongjmp callbacks are passing fine.<br>
with the last (it would be if framePointer = theFP AND !(isBaseFrame: theFP) ) it doesn’t.<br>
<br>
So… from here I’m a bit lost… I need some help :)<br>
<br>
thanks,<br>
Esteban<br>
<br>
<br>
<br>
</blockquote></div><br></div>
</div></blockquote></div><br></div><br></blockquote></div><br></div>
</div></blockquote></div><br></div></div><br></blockquote></div><br></div></div></div></div></div></div>