<p>Jeff,</p>
<p>For what it's worth the situation with 32-bit is exactly the same as 64-bit. Depending on configuration some registers are either cannot be clobbered, or are not saved. You can see an example of compile switches in my fork's bug report that can crash 32-bit greenlet on stock lion's Python.</p>

<p>Regarding cst I already mentioned that it needs to be marked volatile due to double return semantics of stack switches. There was the exact same problem with static globals in greenlet, where slight changes in code would make corruptions go away.</p>

<div class="gmail_quote">On Aug 18, 2011 5:20 PM, "Jeff Senn" <<a href="mailto:senn@maya.com">senn@maya.com</a>> wrote:<br type="attribution">> Anselm - can you have a look and see what you think of Alexey's version? <br>
> Compare with your earlier proposal?  What is you current best version for me to test on OS-X<br>> (preferably w/o the darwin specific compile option which I can't tell if you<br>> thought was necessary or not...)<br>
> <br>> FWIW: My problem with the 32-bit version does seem to have something to do<br>> with the llvm version of gcc on Lion... putting a useless (but not optimize-away-able) <br>> statement directly after the call to slp_switch that refers to cst and cstprev<br>
> causes it to work again... so I suspect either some sort of "bug"<br>> in code generation -- or an optimization that breaks the stack switching...<br>> if this sounds familiar to anyone (before I have time to go rip apart and analyze<br>
> the object code -- which will be awhile), please let me know...<br>> <br>> <br>> On Aug 17, 2011, at 6:09 PM, Alexey Borzenkov wrote:<br>> <br>>> On Fri, May 6, 2011 at 7:27 PM, Estevo <<a href="mailto:euccastro@yahoo.com">euccastro@yahoo.com</a>> wrote:<br>
>>> I got the following error trying to make release27-maint in a 64-bit<br>>>> <br>>>> gcc -pthread -c -fno-strict-aliasing -DSTACKLESS_FRHACK=0 -g -O2 -DNDEBUG -g<br>>>> -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include -I./Stackless<br>
>>> -DPy_BUILD_CORE -fno-omit-frame-pointer -O2 -I. -o Stackless/core/slp_transfer.o<br>>>> ./Stackless/core/slp_transfer.c<br>>>> ./Stackless/core/slp_transfer.c: In function â€˜slp_transfer’:<br>
>>> ./Stackless/core/slp_transfer.c:153:1: error: bp cannot be used in asm here<br>>>> make: *** [Stackless/core/slp_transfer.o] Erro 1<br>>> <br>>> While working on greenlet and fixing switch-related problems, I found<br>
>> that I cornered myself into the same issue with gcc (as opposed to<br>>> llvm-gcc used on OS X Lion). It seems that for whatever reasons gcc<br>>> doesn't allow clobbering rbp when it's using it for referencing stack<br>
>> frame.<br>>> <br>>> Coincidentally I managed to find a way to correctly save rbp (as well<br>>> as csr and cw), that works and compiles both with and without<br>>> -fomit-frame-pointers. In anyone is interested you can find my<br>
>> slp_transfer for amd64 here:<br>>> <br>>> <a href="https://bitbucket.org/snaury/greenlet/src/5d37cde9474c/platform/switch_amd64_unix.h">https://bitbucket.org/snaury/greenlet/src/5d37cde9474c/platform/switch_amd64_unix.h</a><br>
>> <br>>> If anyone can verify it's 100% correct (though redundant), then you<br>>> can maybe use it in stackless too.<br>>> <br>>> _______________________________________________<br>>> Stackless mailing list<br>
>> <a href="mailto:Stackless@stackless.com">Stackless@stackless.com</a><br>>> <a href="http://www.stackless.com/mailman/listinfo/stackless">http://www.stackless.com/mailman/listinfo/stackless</a><br>> <br>> <br>
> _______________________________________________<br>> Stackless mailing list<br>> <a href="mailto:Stackless@stackless.com">Stackless@stackless.com</a><br>> <a href="http://www.stackless.com/mailman/listinfo/stackless">http://www.stackless.com/mailman/listinfo/stackless</a><br>
</div>